OSGi versioning for the curious

143 views
Skip to first unread message

Josh Suereth

unread,
Mar 13, 2012, 8:37:26 AM3/13/12
to scala-i...@googlegroups.com
http://wiki.eclipse.org/Version_Numbering


If you read the above document, you'll see how our version schemes are not cool for OSGi.  In particular, we use our first number (2) to Denote the "era" of scala.   Granted, their 'minor' version number distinction is pretty vague.

In any case, if you're using OSGi, in the future, you should be able to make use of the following knowledge:

<major>.<minor>.<bugfix>.<qualifier>

<major> - Denotes our Epoch of Scala.   Major language change from 1.x to 2.x to 3.x.
<minor> - Denotes binary incompatible API and/or incremental language changes
<bugfix> - Denotes bug fixes that should not break the external/binary API
<qualifier> - lexicographically increasing number used to release snapshots during development.


I'm attempting to stuff GIT information into the <qualifier>, but in a lexicographically increasing way.   Anyone have any suggestions (that work with OSGi), let me know.   Otherwise I'll link to my pull request once my mechanism works.


Thanks!
- Josh

Paul Phillips

unread,
Mar 13, 2012, 1:43:37 PM3/13/12
to scala-i...@googlegroups.com
On Tue, Mar 13, 2012 at 5:37 AM, Josh Suereth <joshua....@gmail.com> wrote:
> I'm attempting to stuff GIT information into the <qualifier>, but in a
> lexicographically increasing way.   Anyone have any suggestions (that work
> with OSGi), let me know.   Otherwise I'll link to my pull request once my
> mechanism works.

Does that include a pull request against

https://github.com/paulp/version-investigator

Because honestly I'd rather never do any of this again.

Josh Suereth

unread,
Mar 13, 2012, 2:27:04 PM3/13/12
to scala-i...@googlegroups.com
No.  I'm just using that to come up with versions that are closely related enough to appear to be the same, but also work in maven/osgi respectively.

We'll have two version numbers.   psuedo code ->

val osgiString = Path("tools/get-scala-version").!!   // Note this is different in my branch.
val osgiVersion = maven version match {
  case something + "-SNAPSHOT"  => something + "-" + osgiString
  case something + "-" + number => something + "-BUILD-" + number + "-" + osgiString
  case something                => something + "-" + osgiString
}

SO, versioning:

maven                  OSGi
----------             --------
2.9.2-SNAPSHOT         2.9.2-20100311-120-5deab6
2.9.2                  2.9.2-20100401-132-a29e11
2.9.2-1                2.9.2-BUILD1-20101113-133-82e12a

Unless my brain is still toast from last week, it appears to have all the properties we want in version numbers *and* should also be useful.   Note:  The OSGi version number will be printed by scalac when run, since it has the most information.

Thoughts?

Odd Möller

unread,
Mar 13, 2012, 2:59:32 PM3/13/12
to scala-i...@googlegroups.com
Shouldn't the fact that a Scala installation was built from a snapshot version (as opposed to from a final one) be reflected in the version string returned by "scala -v"?

Greetings
//Odd

Josh Suereth

unread,
Mar 13, 2012, 3:47:05 PM3/13/12
to scala-i...@googlegroups.com
For the purposes of reporting bugs and finding errors, I don't see how that extra information helps us terribly.   I can certainly add an "R" at the beginning of the version string for releases.   What purpose do you see for such a notation?

Odd Möller

unread,
Mar 13, 2012, 4:12:19 PM3/13/12
to scala-i...@googlegroups.com
Mainly as a way to quickly get a sense of the stability of the installed Scala version when encountering problems (with the assumption that the final builds are in some respect of higher quality). If the version used is a snapshot version, an upgrade to a later version could be attempted, but if it is a final version the problem probably lies elsewhere.

//Odd

Paul Phillips

unread,
Mar 13, 2012, 5:13:14 PM3/13/12
to scala-i...@googlegroups.com
On Tue, Mar 13, 2012 at 11:27 AM, Josh Suereth <joshua....@gmail.com> wrote:
> No.  I'm just using that to come up with versions that are closely related
> enough to appear to be the same, but also work in maven/osgi respectively.

I mention it because even the low ambition case is harder than it
looks, and it will be easier to get it right and keep it right if we
involve some code.

> SO, versioning:
>
> maven                  OSGi
> ----------             --------
> 2.9.2-SNAPSHOT         2.9.2-20100311-120-5deab6
> 2.9.2                  2.9.2-20100401-132-a29e11
> 2.9.2-1                2.9.2-BUILD1-20101113-133-82e12a

None of those is a valid osgi version.

If the character after the 2.9.2 in each osgi case was intended to be
a . then they become valid versions, syntactically. But
2.9.2-SNAPSHOT comes before 2.9.2 in maven, and
2.9.2.20100311-120-5deab6 would come AFTER 2.9.2 in osgi. These are
the kinds of things version-inspector will tell you.

Josh Suereth

unread,
Mar 13, 2012, 5:16:24 PM3/13/12
to scala-i...@googlegroups.com

They are meant to be '.' And plain old 2.9.2 would never occur in the osgi version.  That table was supposed to be my hand gobbled example from what I implemented in ant XML.

The idea is the maven-osgi versions are pairs referring to the same release.

Josh Suereth

unread,
Mar 14, 2012, 12:57:00 AM3/14/12
to scala-i...@googlegroups.com
Ok, so it looks to be passing Paul's version inspector.  Here's the new output of init:

Nightlies --
ant init
init:
     [echo]        build time: 14 March 2012, 00:52:07
     [echo]      java version: OpenJDK 64-Bit Server VM 1.6.0_23
     [echo]         java args: -Xms1536M -Xmx1536M -Xss1M -XX:MaxPermSize=192M -XX:+UseParallelGC 
     [echo]        javac args: 
     [echo]       scalac args: 
     [echo]     maven version: 2.9.2-SNAPSHOT
     [echo]      OSGi version: 2.9.2.DEV-20120314-0175-gb8b51b70b

RCs --
ant -Dmaven.version.suffix=-RC1 init
init:
     [echo]        build time: 14 March 2012, 00:53:58
     [echo]      java version: OpenJDK 64-Bit Server VM 1.6.0_23
     [echo]         java args: -Xms1536M -Xmx1536M -Xss1M -XX:MaxPermSize=192M -XX:+UseParallelGC 
     [echo]        javac args: 
     [echo]       scalac args: 
     [echo]     maven version: 2.9.2-RC1
     [echo]      OSGi version: 2.9.2.DEV-20120314-0175-gb8b51b70bf

FINAL releases
ant -Dbuild.release=true init
init:
     [echo]        build time: 14 March 2012, 00:53:07
     [echo]      java version: OpenJDK 64-Bit Server VM 1.6.0_23
     [echo]         java args: -Xms1536M -Xmx1536M -Xss1M -XX:MaxPermSize=192M -XX:+UseParallelGC 
     [echo]        javac args: 
     [echo]       scalac args: 
     [echo]     maven version: 2.9.2
     [echo]      OSGi version: 2.9.2.FINAL-20120314-0175-gb8b51b70bf


Anyone against?

Paul Phillips

unread,
Mar 14, 2012, 4:56:14 AM3/14/12
to scala-i...@googlegroups.com
On Tue, Mar 13, 2012 at 9:57 PM, Josh Suereth <joshua....@gmail.com> wrote:
> Anyone against?

The whole approach makes me pretty nervous. Can you elaborate it all
the way out? What are the equivalent OSGI versions for 2.10.0-M1,
2.9.1-1, etc? When there is a date in the name, what is that date? The
date the build was run? The git author date? The git committer date?
What time zone? Does building revision N+1 yesterday give a build
string which falls earlier or later than building revision N today?
Using the date string is to be the primary sorting key for every
development version will very likely go wrong. That's why git doesn't
do it, and uses distance from a reference commit.

There's not a lot of alphabet between DEV and FINAL, is the plan t

Paul Phillips

unread,
Mar 14, 2012, 4:56:41 AM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 1:56 AM, Paul Phillips <pa...@improving.org> wrote:
> There's not a lot of alphabet between DEV and FINAL, is the plan t

Thanks chrome, that was originally "There's not a lot of alphabet
between DEV and FINAL, is the plan to put everything including
milestones under DEV?"

iulian dragos

unread,
Mar 14, 2012, 6:44:38 AM3/14/12
to scala-i...@googlegroups.com
Josh, thanks a lot for putting this together.

It looks good to me. I'd add the time to the timestamp, since there may be more than one build published in a day (there have been cases when we needed a bugfix in the compiler, and pick it up in a subsequent IDE build) -- or maybe the 'git describe' string coming afterwards takes care of that?

I'm not so worried about using a timestamp there, because anything that gets published under org.scala-lang should be built by the EPFL Jenkins jobs. Timestamps are standard practice in OSGi AFAICT, including the release version of Eclipse SDK (for instance: 3.7.1.M20110909-1335).

I am a bit disappointed the RC1 would be gone in the OSGi version. What would 'scala -v' show for 2.9.2-RC1?

cheers,
iulian

 

On Tue, Mar 13, 2012 at 5:16 PM, Josh Suereth <joshua....@gmail.com> wrote:

They are meant to be '.' And plain old 2.9.2 would never occur in the osgi version.  That table was supposed to be my hand gobbled example from what I implemented in ant XML.

The idea is the maven-osgi versions are pairs referring to the same release.

On Mar 13, 2012 5:13 PM, "Paul Phillips" <pa...@improving.org> wrote:
On Tue, Mar 13, 2012 at 11:27 AM, Josh Suereth <joshua....@gmail.com> wrote:
> No.  I'm just using that to come up with versions that are closely related
> enough to appear to be the same, but also work in maven/osgi respectively.

I mention it because even the low ambition case is harder than it
looks, and it will be easier to get it right and keep it right if we
involve some code.

> SO, versioning:
>
> maven                  OSGi
> ----------             --------
> 2.9.2-SNAPSHOT         2.9.2-20100311-120-5deab6
> 2.9.2                  2.9.2-20100401-132-a29e11
> 2.9.2-1                2.9.2-BUILD1-20101113-133-82e12a

None of those is a valid osgi version.

If the character after the 2.9.2 in each osgi case was intended to be
a . then they become valid versions, syntactically.  But
2.9.2-SNAPSHOT comes before 2.9.2 in maven, and
2.9.2.20100311-120-5deab6 would come AFTER 2.9.2 in osgi.  These are
the kinds of things version-inspector will tell you.




--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Mirco Dotta

unread,
Mar 14, 2012, 6:46:19 AM3/14/12
to scala-i...@googlegroups.com
Hi Josh,

I'm a bit worried about what will happen to people that currently have Scala IDE 2.0.0 installed. 

The compiler.jar we currently package with the Scala IDE 2.0.0 has the following version 2.9.2.rdev-2769-2011-12-13-g2dd83da
If we ship a maintenance release of the Scala IDE with 2.9.2 final and the proposed OSGi versioning scheme, I'm not sure what 
are the consequences. My main concern is that 2.9.2.FINAL-<xxx> < 2.9.2.rdev-<xxx>, and hence it could be possible 
that when upgrading the Scala IDE, the old compiler jar (2.9.2.rdev-) will be used instead of the new one.

Unfortunately, my understanding of how Eclipse handles upgrade is not as clear as it should be. I'll try to document myself and 
provide more information about this point if I manage to find them. 

One more thing: What will it be the answer of `scala -v`? The maven version? The OSGi one? Neither of them? It would be useful 
if the OSGi version and `scala -v` could provide very similar answers, so that from one you can easily derive the other.

Here is my suggestion for versioning (which I still need to validate against Paul's version-investigator):

Maven -> OSGi

2.9.2-SNAPSHOT -> 2.9.2.dev-<xxx>
2.9.2-M1-> 2.9.2.m1-<xxx>
2.9.2-RC1-> 2.9.2.rc1-<xxx>

2.9.2 (final) -> 2.9.2.v0-<xxx>
2.9.2-1 (final) -> 2.9.2.v1-<xxx>

Where the <xxx> is monotonically increasing at every build (independently of where the build is actually executed, i.e., time needs to be absolute).

But I'm missing what is the answer of `scala -v`.

-- Mirco


---------------
Mirco Dotta
Typesafe - The software stack for applications that scale
PSE-D, 1015 Lausanne, Switzerland
Twitter: @mircodotta








Josh Suereth

unread,
Mar 14, 2012, 6:49:43 AM3/14/12
to scala-i...@googlegroups.com

Yes.  Milestones fall under dev.  Dates are meant to always be UTC of build time, the middle number is the current git describe "# of commits since x" which should resolve timing issues.

Marking the version FINAL for releases move it into its own category where it immediately wins against any milestone/RC.

The maven versions just use canonical maven hackery to exhibit the same behavior.

Note:  this scheme makes life easier if we stick to major-minor-bugfix versions.  If we do build numbers again, it's mildly terrible for OSGi, although if we base the commit range on the same tag, we should be all good.

Note: if we translate our tags to lexicographically sorted strings with no '.'s I can use them too.  I think I learned enough windows batch to make that happen.   The downside is that this is usually a string quite close to major-minor-bugfix.

- Josh

Josh Suereth

unread,
Mar 14, 2012, 6:52:17 AM3/14/12
to scala-i...@googlegroups.com

Well R throws an issue in the alphabet.  I was debating using EA for RC in osgi, so sorting is correct.

As for multiple builds on the same day, notice the commits since tag X in there.  That should bump two builds on the same day since the one with more commits wins.  That may not be ideal, but it seemed good as I was thinking things through.

Josh Suereth

unread,
Mar 14, 2012, 6:54:33 AM3/14/12
to scala-i...@googlegroups.com

I think you picked a better scheme here.  I'll use this one.

Scala -version would return the OSGi version, since it gives us the most useful debugging info.

Mirco Dotta

unread,
Mar 14, 2012, 7:03:14 AM3/14/12
to scala-i...@googlegroups.com

I think you picked a better scheme here.  I'll use this one.

Actually, I'm now wondering about 2.9.2.m1-<xxx>2.9.2.dev-<xxx>, which may or may not be ideal. 

WDYT?

Mirco Dotta

unread,
Mar 14, 2012, 7:12:53 AM3/14/12
to scala-i...@googlegroups.com
2.9.2 (final) -> 2.9.2.v0-<xxx>
2.9.2-1 (final) -> 2.9.2.v1-<xxx>

And, if there are ever going to be more than nine "hotfix" releases, then this should be 

2.9.2 (final) -> 2.9.2.v00-<xxx>
2.9.2-1 (final) -> 2.9.2.v01-<xxx>


√iktor Ҡlang

unread,
Mar 14, 2012, 7:15:19 AM3/14/12
to scala-i...@googlegroups.com
Semantics in version identifiers is so bad it hurts my intellect.
--
Viktor Klang

Akka Tech Lead
Typesafe - The software stack for applications that scale

Twitter: @viktorklang

Josh Suereth

unread,
Mar 14, 2012, 9:35:09 AM3/14/12
to scala-i...@googlegroups.com
So with my patches, this is what starting scala 2.9.2-RC1 may look like:

Welcome to Scala version 2.9.2.dev-20120314-0178-ga8b5d8a349(2.9.2-RC1) (OpenJDK 64-Bit Server VM, Java 1.6.0_23).


2012/3/14 √iktor Ҡlang <viktor...@gmail.com>

Paul Phillips

unread,
Mar 14, 2012, 10:29:43 AM3/14/12
to scala-i...@googlegroups.com
Here are the unique fourth quadrants from the non-scala jars in my
eclipse folder. I'm thinking we ought to mimic what everyone else
does more closely in the osgi version, which means don't even bother
with "DEV" and "FINAL" and attempts to attach meaning and just
timestamp it. Let the maven version have the meanings.


201106241814
v20110823
v201101211721
20111221
v201101211617
v201103041518
v20120109-1030
v201101211617
v201012070820
v201101211617
v201101211721
v20100421-0704
v201101211721
v20100421-0704
v201101211721
20110613132200
v20120110-1739
I20110208-0800
R37x_v20111109-0800
v20100505
I20110111-0800
v20110423-0524
I20100824-0800
I20110222-0800
I20110111-0800
v20110228
v20111007_r372
v20110928-1504
v20110423-0524
v20120113-1953
I20110511-0800
v20120125-1505
v20110110
v20110505
v20100505
v20110110
v20110928-1503
v201202080800
v20111129-2031
v20111129-1423_r372
v20110531-2218
v20110321
v20110523
v20110502
R37x_v20110701
v20110502
v20110815-1438
v20110502
v20100503
v20110502
64_1.1.101.v20120109-1504
v20110502
v20110815-1419
v20120113-1346
v20111126-0153
v20111126-0211
v20110815-1419
R37x_v20111003
v20110815-1419
v20110815-1438
v20110815-1419
R37x_v20111111
v20110815-1438
v20110815-1419
v20120113-1346
v20110815-1438
v20120113-1346
v20110815-1419
v20111128-0624
R37x_v20111103
v20110815-1419
v20120113-1346
v20110815-1419
v20120111-2020
R37x_v20110810-1611
v20100503
R37x_v20110822-1018
v20101004
R37x_v20110822-1018
v20110815-1438
v20110502
v20110425
v201202080800
v20110426
r37_20110819
r37_20110929
v20110426
v20110420-1015
v20110305-1450
v0110816-0800
v_B79_R37x
v20110928-1453
v20120119-1537
v20111006_r372
v20120120-1417
r372_v20111103
v20110928-1453
v20111006_r372
v201202080800
v20120109-1427
v201202080800
I20100907-0800
v20110928-1505
v20111213-1208
v20110928-1505
I20110514-0800
R37x_v20111201-1600
r372_v20111101-0700
v20110928-1453
v20110513
v20120110-1415
v20110110
v20120110-1415
v20111129-2053
v20110803_r371
v20111129-2053
v20111116-2009
v20120103_r372
v20120120-1417
v20100601
v20111213-1754
v20110928-1516
v20110506
v20110928-1516
v201202080800
v20110516
v20120103_r372
v20110928-1516
v20120103_r372
v201202080800
v20120120-1417
r372_v20111202
v201202080800
v20110928-1504
64.source_3.7.2.v3740f
64_3.7.2.v3740f
v3740f
I20110525-0800
I20110510-0800
I20110511-0800
v20120126-1227
R37x_v20111109-0800
v20110928-1504
v20111019-1723
v20110425
I20101109-0800
v20111007_r372
v20110928-1504
v20111007_r372
v20111011-1919
I20110306-2000
v20110928-1505
v20110425
v20110510
v20110425
v20110928-1505
v20120106-1355
v20111208-1155
I20100517-1500
v20110928-1505
v20110404
v20110928-1505
I20110413-1600
v20120104-1859
v20110928-1504
v20120104-1859
v20110928-1505
v20100512
v20110330
v20100512
v20090501071000
v3_8_2_v20100427-1100
v4_8_2_v20110321-1705
v20100525
v3_8_2_v20100427-1100
v4_8_2_v20110321-1705
v201012071420
v201105211655
v20110329

Paul Phillips

unread,
Mar 14, 2012, 10:34:33 AM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 3:54 AM, Josh Suereth <joshua....@gmail.com> wrote:
> Scala -version would return the OSGi version, since it gives us the most
> useful debugging info.

That's another reason to follow the previous suggestion. I see no
reason to confuse everyone by displaying the osgi version anywhere
outside of osgi. Even lowly programmers, who will presumably
eventually figure out why we call it two different things, are worthy
of our sympathy.

√iktor Ҡlang

unread,
Mar 14, 2012, 10:39:33 AM3/14/12
to scala-i...@googlegroups.com
*applause* :-)

Josh Suereth

unread,
Mar 14, 2012, 10:41:31 AM3/14/12
to scala-i...@googlegroups.com
Well, remember the maven version does not include date, nor does it include git hash.

How bout I simplify the OSGi version and still show both?

iulian dragos

unread,
Mar 14, 2012, 11:09:54 AM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 3:29 PM, Paul Phillips <pa...@improving.org> wrote:
Here are the unique fourth quadrants from the non-scala jars in my
eclipse folder.  I'm thinking we ought to mimic what everyone else
does more closely in the osgi version, which means don't even bother
with "DEV" and "FINAL" and attempts to attach meaning and just
timestamp it.  Let the maven version have the meanings.

That's not very helpful. At a minimum, I need the git hash. Ideally, something similar enough (after the timestamp) to what `scala -v` says. The timestamp ensures increasing version numbers, so we can put what `scala -v` says afterwards (the current scheme, `git --described` looks good).

cheers,
iulian

Paul Phillips

unread,
Mar 14, 2012, 11:32:44 AM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 7:41 AM, Josh Suereth <joshua....@gmail.com> wrote:
> Well, remember the maven version does not include date, nor does it include
> git hash.

So by "maven version" here we mean x.y.z-SNAPSHOT, yes?

To me this says unnamed development builds should go like this:

Canonical version, printed by scalac -version:
x.y.z-buildstring-with-githash-date-whatever
Maven version: x.y.z-SNAPSHOT
OSGI version: x.y.z.yyyymmddhhss

> At a minimum, I need the git hash.

We can of course append it to the osgi time snapshot, but what does
"need" mean in this context? You'll have access to it regardless, it
can and should be in the properties file. It can't be necessary for
ordering the builds since to-the-second timestamps aren't going to
leave much room for tiebreakers.

There's no reason it can't be in the osgi version if you need it, but
I'm resisting duplicating the information into more places than
necessary, and everything we add to the osgi version string represents
a point of future failure and/or difficulty in changing.

We should even have a command line option just to get the git hash, so
you can say

git log -n1 $(scalac -build-commit)

or whatever.

iulian dragos

unread,
Mar 14, 2012, 11:42:50 AM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 4:32 PM, Paul Phillips <pa...@improving.org> wrote:
On Wed, Mar 14, 2012 at 7:41 AM, Josh Suereth <joshua....@gmail.com> wrote:
> Well, remember the maven version does not include date, nor does it include
> git hash.

So by "maven version" here we mean x.y.z-SNAPSHOT, yes?

To me this says unnamed development builds should go like this:

 Canonical version, printed by scalac -version:
x.y.z-buildstring-with-githash-date-whatever
 Maven version: x.y.z-SNAPSHOT
 OSGI version: x.y.z.yyyymmddhhss

> At a minimum, I need the git hash.

We can of course append it to the osgi time snapshot, but what does
"need" mean in this context?

I need to be able to know, based on the version number that people see in their Eclipse installation details, if a certain commit is or is not in their build. Timestamps fix the ordering issues, but there's also some useful information that should be part of that qualifier.

 
You'll have access to it regardless, it
can and should be in the properties file.

Not sure how, short of unzipping the jar. I think that would make it way too difficult for people to report meaningful bugs, or even for myself when debugging an issue.

thanks,
iulian
 
 It can't be necessary for
ordering the builds since to-the-second timestamps aren't going to
leave much room for tiebreakers.

There's no reason it can't be in the osgi version if you need it, but
I'm resisting duplicating the information into more places than
necessary, and everything we add to the osgi version string represents
a point of future failure and/or difficulty in changing.

We should even have a command line option just to get the git hash, so
you can say

 git log -n1 $(scalac -build-commit)

or whatever.

Daniel Sobral

unread,
Mar 14, 2012, 11:55:21 AM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 08:12, Mirco Dotta <mirco...@typesafe.com> wrote:
>> 2.9.2 (final) -> 2.9.2.v0-<xxx>
>> 2.9.2-1 (final) -> 2.9.2.v1-<xxx>
>
>
> And, if there are ever going to be more than nine "hotfix" releases, then
> this should be
>
> 2.9.2 (final) -> 2.9.2.v00-<xxx>
> 2.9.2-1 (final) -> 2.9.2.v01-<xxx>

But how likely is that? It gets to be more trouble to release a hotfix
than to go to the next bugfix release, particularly given the current
schedules on minor/bugfix releases.

Also, if ever that schedule becomes more sedate, one can go to the
double-digits hotfix version without backward compatibility problems,
since the major/minor/bugix version would take precedence.

--
Daniel C. Sobral

I travel to the future all the time.

Paul Phillips

unread,
Mar 14, 2012, 11:57:00 AM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 8:42 AM, iulian dragos <jagu...@gmail.com> wrote:
> I need to be able to know, based on the version number that people see in
> their Eclipse installation details, if a certain commit is or is not in
> their build.

OK, that's a good reason. So would .<timestamp>-<sha> suffice?

We should drop the 'g', too, as long as we're molding these things for
our own purposes. (For those unaware, git prepends the 'g' as a nod
to SCM-independence; it means "git".) I seriously question its
utility, but I also like to avoid deviating from defaults without just
cause.

Mirco Dotta

unread,
Mar 14, 2012, 12:02:06 PM3/14/12
to scala-i...@googlegroups.com
On Mar 14, 2012, at 4:55 PM, Daniel Sobral wrote:

On Wed, Mar 14, 2012 at 08:12, Mirco Dotta <mirco...@typesafe.com> wrote:
2.9.2 (final) -> 2.9.2.v0-<xxx>
2.9.2-1 (final) -> 2.9.2.v1-<xxx>


And, if there are ever going to be more than nine "hotfix" releases, then
this should be

2.9.2 (final) -> 2.9.2.v00-<xxx>
2.9.2-1 (final) -> 2.9.2.v01-<xxx>

But how likely is that? It gets to be more trouble to release a hotfix
than to go to the next bugfix release, particularly given the current
schedules on minor/bugfix releases.

Also, if ever that schedule becomes more sedate, one can go to the
double-digits hotfix version without backward compatibility problems,
since the major/minor/bugix version would take precedence.

Hi Daniel,

Yes, I guess I was being overcautious. Anyway, now I am of the idea it is better 
 to adopt a scheme where build numbers are not meaningful for ordering, 
i.e., 2.9.2.vYYYYHHMM-XXX where XXX can be anything that provides enough 
information to a user to understand what Scala version is linked to.

Adriaan Moors

unread,
Mar 14, 2012, 12:01:37 PM3/14/12
to scala-i...@googlegroups.com
+1 -- i've more than once wondered why i couldn't find the commit for my scalac build (until i remembered g is not in hex's alphabet)

Mirco Dotta

unread,
Mar 14, 2012, 12:03:32 PM3/14/12
to scala-i...@googlegroups.com
+1 -- i've more than once wondered why i couldn't find the commit for my scalac build (until i remembered g is not in hex's alphabet)

+10! I'm glad I wasn't the only one :)


On Wed, Mar 14, 2012 at 4:57 PM, Paul Phillips <pa...@improving.org> wrote:
We should drop the 'g', too, as long as we're molding these things for
our own purposes.  (For those unaware, git prepends the 'g' as a nod
to SCM-independence; it means "git".) I seriously question its
utility, but I also like to avoid deviating from defaults without just
cause.

Grzegorz Kossakowski

unread,
Mar 14, 2012, 12:15:17 PM3/14/12
to scala-i...@googlegroups.com
On 14 March 2012 16:42, iulian dragos <jagu...@gmail.com> wrote:

I need to be able to know, based on the version number that people see in their Eclipse installation details, if a certain commit is or is not in their build. Timestamps fix the ordering issues, but there's also some useful information that should be part of that qualifier.

I'm really worried about the idea of attaching timestamps of builds to version numbers. This way we make our builds non-reproducible which I learnt the hard way yesterday while working with Scala virtualized. I created a custom branch of scala with some patches attached, published scala to Maven repo locally and modified a bunch of my projects to depend on that version. I shared the result with Nada and it turned out that she has no way to reproduce my results even if she has all necessary branches checked out because scala builds are not reproducible.

Since we switched to distributed version system we need to embrace an idea of distributed (reproducible!) builds as well. I know that in other contexts you have different needs and that's why I think "one size fits all" approach to version numbers is not going to get us anywhere.

Based on all I read about version numbers I propose we come up with different versioning schemes serving different needs. I think we should start by identifying those, first.

--
Grzegorz Kossakowski

iulian dragos

unread,
Mar 14, 2012, 12:24:46 PM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 5:15 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:
On 14 March 2012 16:42, iulian dragos <jagu...@gmail.com> wrote:

I need to be able to know, based on the version number that people see in their Eclipse installation details, if a certain commit is or is not in their build. Timestamps fix the ordering issues, but there's also some useful information that should be part of that qualifier.

I'm really worried about the idea of attaching timestamps of builds to version numbers. This way we make our builds non-reproducible which I learnt the hard way yesterday while working with Scala virtualized. I created a custom branch of scala with some patches attached, published scala to Maven repo locally and modified a bunch of my projects to depend on that version. I shared the result with Nada and it turned out that she has no way to reproduce my results even if she has all necessary branches checked out because scala builds are not reproducible.

Any other suggestions? It's hard enough to come up with something that people agree, so please don't throw us back to square one without some proposal we can discuss. The requirements are simple enough: a scheme that increases monotonically using the OSGi rules, and that can behave reasonable with both snapshots and released versions.

thanks,
iulian
 

Since we switched to distributed version system we need to embrace an idea of distributed (reproducible!) builds as well. I know that in other contexts you have different needs and that's why I think "one size fits all" approach to version numbers is not going to get us anywhere.

Based on all I read about version numbers I propose we come up with different versioning schemes serving different needs. I think we should start by identifying those, first.

--
Grzegorz Kossakowski

Adriaan Moors

unread,
Mar 14, 2012, 12:25:36 PM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 5:15 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:
because scala builds are not reproducible.
how come?

Lukas Rytz

unread,
Mar 14, 2012, 12:25:55 PM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 17:15, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:
On 14 March 2012 16:42, iulian dragos <jagu...@gmail.com> wrote:

I need to be able to know, based on the version number that people see in their Eclipse installation details, if a certain commit is or is not in their build. Timestamps fix the ordering issues, but there's also some useful information that should be part of that qualifier.

I'm really worried about the idea of attaching timestamps of builds to version numbers. This way we make our builds non-reproducible which I learnt the hard way yesterday while working with Scala virtualized. I created a custom branch of scala with some patches attached, published scala to Maven repo locally and modified a bunch of my projects to depend on that version. I shared the result with Nada and it turned out that she has no way to reproduce my results even if she has all necessary branches checked out because scala builds are not reproducible.

agree. will the git committer date do (paul mentioned it before)? does it play
well with merges, linearizing history?

lampmac1:scala luc$ git log --pretty=format:'%ct-%H' -n 1
1331486613-ee51b6e1b1bc4bd60e6f6bbaea6eb3d4be8b3c97

Grzegorz Kossakowski

unread,
Mar 14, 2012, 12:33:33 PM3/14/12
to scala-i...@googlegroups.com

Because the next day you publish the same Git sha1 it's going to be published with different timestamp. You cannot reproduce yesterday results without tweaking your system clock or hacking build scripts.

-- Sent from Android

Josh Suereth

unread,
Mar 14, 2012, 12:34:55 PM3/14/12
to scala-i...@googlegroups.com

Guys we already have 3 numbers for different use cases.

(1) maven releases.  If you want reproducible builds in maven don't use snapshots.  They're broken.
(2) osgi releases.  This version is designed so that compatible newer versions override older ones.
(3) our internal bugfix info.  We can do whatever.

Paul Phillips

unread,
Mar 14, 2012, 12:44:27 PM3/14/12
to scala-i...@googlegroups.com
On Wed, Mar 14, 2012 at 9:33 AM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> Because the next day you publish the same Git sha1 it's going to be
> published with different timestamp. You cannot reproduce yesterday results
> without tweaking your system clock or hacking build scripts.

That's exactly the kind of thing I was afraid of when timestamps were
first mentioned. I'm "glad" to see it's actually a problem (only glad
in the sense that if it's going to be a problem, better to have a
concrete example now.)

Since we should be speaking in code, not words:

https://github.com/paulp/version-investigator

The following is NOT my proposal wrt versions. The point is to get us
speaking in code. Send me your pull requests.

bin/generateVersions 2.9.1 1 79e937bea2 20120314-0923

Outputs at this writing - strawman only - to be refined until
satisfactory to all:

Arguments:
"2.9.1"
"1"
"79e937bea2"
"20120314-0923"

Release:
canonical: 2.9.1-1-79e937bea2-20120314-0923
osgi: 2.9.1.20120314-0923-1-79e937bea2
maven: 2.9.1-1

Development:
canonical: 2.9.1-1-79e937bea2-20120314-0923
osgi: 2.9.1.20120314-0923-1-79e937bea2
maven: 2.9.1-1-SNAPSHOT

Josh Suereth

unread,
Mar 14, 2012, 2:24:59 PM3/14/12
to scala-i...@googlegroups.com

My pull request is on scala / scala.   I still stand by what I had as no better or worse than any proposals I've seen.

Chris Marshall

unread,
Mar 15, 2012, 1:32:51 PM3/15/12
to scala-i...@googlegroups.com
In the InfoQ interview [1] Martin said "Scala currently breaks binary compatibility with major releases. Minor releases have been binary compatible for a while now" (unless misquoted). It would have sounded less impressive as "bugfix releases have been binary compatible for a while now"

Chris

[1] ( http://www.infoq.com/articles/odersky-scala-interview )


From: joshua....@gmail.com
Date: Tue, 13 Mar 2012 08:37:26 -0400
Subject: [scala-internals] OSGi versioning for the curious
To: scala-i...@googlegroups.com

http://wiki.eclipse.org/Version_Numbering


If you read the above document, you'll see how our version schemes are not cool for OSGi.  In particular, we use our first number (2) to Denote the "era" of scala.   Granted, their 'minor' version number distinction is pretty vague.

In any case, if you're using OSGi, in the future, you should be able to make use of the following knowledge:

<major>.<minor>.<bugfix>.<qualifier>

<major> - Denotes our Epoch of Scala.   Major language change from 1.x to 2.x to 3.x.
<minor> - Denotes binary incompatible API and/or incremental language changes
<bugfix> - Denotes bug fixes that should not break the external/binary API
<qualifier> - lexicographically increasing number used to release snapshots during development.


I'm attempting to stuff GIT information into the <qualifier>, but in a lexicographically increasing way.   Anyone have any suggestions (that work with OSGi), let me know.   Otherwise I'll link to my pull request once my mechanism works.


Thanks!
- Josh

Josh Suereth

unread,
Mar 15, 2012, 1:39:30 PM3/15/12
to scala-i...@googlegroups.com
bugfix releaseas *are* minor releases for scala.   We take the four version approach: <2>.<major>.<minor>-<bugfix>

Where 2 means "Written in Scala" and 3 might mean "New typesystem".

- Josh

martin odersky

unread,
Mar 15, 2012, 1:57:31 PM3/15/12
to scala-i...@googlegroups.com
On Thu, Mar 15, 2012 at 6:32 PM, Chris Marshall <oxbow...@hotmail.com> wrote:
> In the InfoQ interview [1] Martin said "Scala currently breaks binary
> compatibility with major releases. Minor releases have been binary
> compatible for a while now" (unless misquoted). It would have sounded less
> impressive as "bugfix releases have been binary compatible for a while now"
>
> Chris
>
Minor releases are not bugfix releases. We do add library
functionality in them, but make sure we stay binary compatible. This
is a hard problem, and we have poured considerable resources in
assuring binary compatibility. It would be nice to see this
appreciated by the community instead of being belittled.

Thanks

-- Martin

Grzegorz Kossakowski

unread,
Mar 15, 2012, 2:17:10 PM3/15/12
to scala-i...@googlegroups.com
On 14 March 2012 19:24, Josh Suereth <joshua....@gmail.com> wrote:

My pull request is on scala / scala.   I still stand by what I had as no better or worse than any proposals I've seen.

Josh, I guess you are talking about:


This pull requests affects 2.9.x and not master. Am I correct that you would like to get those changes cherry-picked for master as well?

--
Grzegorz Kossakowski

Grzegorz Kossakowski

unread,
Mar 15, 2012, 2:33:09 PM3/15/12
to scala-i...@googlegroups.com
On 14 March 2012 17:25, Lukas Rytz <lukas...@epfl.ch> wrote:
agree. will the git committer date do (paul mentioned it before)? does it play
well with merges, linearizing history?

lampmac1:scala luc$ git log --pretty=format:'%ct-%H' -n 1
1331486613-ee51b6e1b1bc4bd60e6f6bbaea6eb3d4be8b3c97

I don't see immediately (after one day of pondering this) a reason why it wouldn't work.


Any other suggestions? It's hard enough to come up with something that people agree, so please don't throw us back to square one without some proposal we can discuss. The requirements are simple enough: a scheme that increases monotonically using the OSGi rules, and that can behave reasonable with both snapshots and released versions.

What about a suggestion to take whatever has been proposed so far and just replace a timestamp coming from a machine running a build into a timestamp of a commit that is being built at the moment in UTC timezone?

Since we never force when pushing to scala/scala branches (like master or 2.9.x) we are going to have monotonically increasing timestamps guaranteed.

I'll take Paul's advice and use his versioning tool but I'd like to know if anybody sees any obvious problem with this proposal?

--
Grzegorz Kossakowski

Josh Suereth

unread,
Mar 15, 2012, 2:33:29 PM3/15/12
to scala-i...@googlegroups.com
Yes.  However, for now I need to update 2.9.x branch so I can release RC1

Josh Suereth

unread,
Mar 15, 2012, 2:35:43 PM3/15/12
to scala-i...@googlegroups.com
git cherry-pick ruins having monotonically increasing dates IIRC.  It preserves the date of the original commit, so merging patches between branches gets odd dates (by default).

Grzegorz Kossakowski

unread,
Mar 15, 2012, 2:37:14 PM3/15/12
to scala-i...@googlegroups.com
On 14 March 2012 17:34, Josh Suereth <joshua....@gmail.com> wrote:

Guys we already have 3 numbers for different use cases.

(1) maven releases.  If you want reproducible builds in maven don't use snapshots.  They're broken.


I agree. That's why I switched from 2.10.0-virtualized-SNAPSHOT version to something like
"2.10.0-M2-0020-geab3b7e4d7-2012-03-06 " and used ant deploy.release.local for deploying to local Maven repo. I'd be happy with such a version (or any permutation of it's segments that satisfies osgi) as long as the whole version depends on info from Git repo and not on machine settings it's been ran on.

(2) osgi releases.  This version is designed so that compatible newer versions override older ones.
(3) our internal bugfix info.  We can do whatever.



--
Grzegorz Kossakowski

Chris Marshall

unread,
Mar 15, 2012, 2:50:20 PM3/15/12
to scala-i...@googlegroups.com
No-one was belittling anything. I was pointing out, in my usual ham-fisted way, that what you stated was in apparent contradiction with Josh's statement of what scala build number meant. Quoting Josh again:

  > <major> - Denotes our Epoch of Scala.   Major language change from 1.x to 2.x to 3.x.
  > <minor> - Denotes binary incompatible API and/or incremental language changes
  > <bugfix> - Denotes bug fixes that should not break the external/binary API
  > <qualifier> - lexicographically increasing number used to release snapshots during development.

To me, this says that 2 is a major version and 10 is a minor version; so now I am confused about which is which

Chris


> From: martin....@epfl.ch
> Date: Thu, 15 Mar 2012 18:57:31 +0100
> Subject: Re: [scala-internals] OSGi versioning for the curious
> To: scala-i...@googlegroups.com
>

Grzegorz Kossakowski

unread,
Mar 15, 2012, 2:50:07 PM3/15/12
to scala-i...@googlegroups.com
On 15 March 2012 19:35, Josh Suereth <joshua....@gmail.com> wrote:
git cherry-pick ruins having monotonically increasing dates IIRC.  It preserves the date of the original commit, so merging patches between branches gets odd dates (by default).

Not really, that's why I proposed using git commit timestamp and not git author timestamp. Let me illustrate with an example:

eduroam-10-20-6-9:git-times grek (master)$ git log master --format=fuller
commit 86280488f6d1f91bbaa68156c6c7f47d04238bfc
Author:     Grzegorz Kossakowski <grzegorz.k...@gmail.com>
AuthorDate: Thu Mar 15 19:41:43 2012 +0100
Commit:     Grzegorz Kossakowski <grzegorz.k...@gmail.com>
CommitDate: Thu Mar 15 19:41:43 2012 +0100

    bar

[...]

eduroam-10-20-6-9:git-times grek (master)$ git log otherbranch --format=fuller
commit f3169ceeae5e4c90586844f65381527cd3ebd4b1
Author:     Grzegorz Kossakowski <grzegorz.k...@gmail.com>
AuthorDate: Thu Mar 15 19:41:43 2012 +0100
Commit:     Grzegorz Kossakowski <grzegorz.k...@gmail.com>
CommitDate: Thu Mar 15 19:42:08 2012 +0100

    bar
 
[...]

What I did here was cherrypicking bar commit to other branch. As you can see in the original commit both AuthorDate and CommitDate were the same. However, once I cherry-picked the commit AuthorDate has been kept (Git always keeps it) and CommitDate has been updated because Git was really creating a new commit object.

The same distinction is preserved when you do rebasing. So when you rebase your commits they will keep original AuthorDate but will get CommitDate updated.

AFAIK, we are safe on this front.

--
Grzegorz Kossakowski

Josh Suereth

unread,
Mar 15, 2012, 2:52:53 PM3/15/12
to scala-i...@googlegroups.com
AHHH, k. I  get those confused *all the time*.

Josh Suereth

unread,
Mar 15, 2012, 2:59:41 PM3/15/12
to scala-i...@googlegroups.com
Right, so there's a debate of what *we scala developers* consider a major version, vs. the "canonical" "put digits here for this value" enforcement of maven/osgi.

We ignore Maven OSGi in favor of marketing.  Lots of folks do it.   IF you look below, that's the mapping from *maven* version requirements to what they mean in Scala.

2.9 -> 2.10 is considered a major release for Scala.

2.9.0 -> 2.9.1 is considered a minor release.

2.9.1 -> 2.9.1-1 is considered a bugfix release.

You see, the versioning scheme is one size fits all, and the Scala versions were in place long before the scheme was forced on us all.

- Josh

iulian dragos

unread,
Mar 15, 2012, 4:49:37 PM3/15/12
to scala-i...@googlegroups.com
On Thu, Mar 15, 2012 at 7:33 PM, Grzegorz Kossakowski <grzegorz.k...@gmail.com> wrote:
On 14 March 2012 17:25, Lukas Rytz <lukas...@epfl.ch> wrote:
agree. will the git committer date do (paul mentioned it before)? does it play
well with merges, linearizing history?

lampmac1:scala luc$ git log --pretty=format:'%ct-%H' -n 1
1331486613-ee51b6e1b1bc4bd60e6f6bbaea6eb3d4be8b3c97

I don't see immediately (after one day of pondering this) a reason why it wouldn't work.


Any other suggestions? It's hard enough to come up with something that people agree, so please don't throw us back to square one without some proposal we can discuss. The requirements are simple enough: a scheme that increases monotonically using the OSGi rules, and that can behave reasonable with both snapshots and released versions.

What about a suggestion to take whatever has been proposed so far and just replace a timestamp coming from a machine running a build into a timestamp of a commit that is being built at the moment in UTC timezone?

Sounds good! Thanks!
 

Since we never force when pushing to scala/scala branches (like master or 2.9.x) we are going to have monotonically increasing timestamps guaranteed.

I'll take Paul's advice and use his versioning tool but I'd like to know if anybody sees any obvious problem with this proposal?

--
Grzegorz Kossakowski

Grzegorz Kossakowski

unread,
Mar 15, 2012, 5:01:25 PM3/15/12
to scala-i...@googlegroups.com
On 15 March 2012 21:49, iulian dragos <jagu...@gmail.com> wrote:

What about a suggestion to take whatever has been proposed so far and just replace a timestamp coming from a machine running a build into a timestamp of a commit that is being built at the moment in UTC timezone?

Sounds good! Thanks!

It looks like we have an agreement, right? :-) 

Josh, 

Do you want to update your pull request with what we discussed? I guess you are the most knowledgeable person about 2.9.x situation. I can take care of master if you want.

--
Grzegorz Kossakowski

Josh Suereth

unread,
Mar 15, 2012, 5:05:36 PM3/15/12
to scala-i...@googlegroups.com

I'll take care of it this evening, as well as a 2.9.2-RC1 assuming everyone is in agreement.

On Mar 15, 2012 5:01 PM, "Grzegorz Kossakowski" <grzegorz.k...@gmail.com> wrote:

martin odersky

unread,
Mar 15, 2012, 5:11:26 PM3/15/12
to scala-i...@googlegroups.com
On Thu, Mar 15, 2012 at 7:50 PM, Chris Marshall <oxbow...@hotmail.com> wrote:
> No-one was belittling anything. I was pointing out, in my usual ham-fisted
> way, that what you stated was in apparent contradiction with Josh's
> statement of what scala build number meant. Quoting Josh again:
>
>   > <major> - Denotes our Epoch of Scala.   Major language change from 1.x
> to 2.x to 3.x.
>   > <minor> - Denotes binary incompatible API and/or incremental language
> changes
>   > <bugfix> - Denotes bug fixes that should not break the external/binary
> API
>   > <qualifier> - lexicographically increasing number used to release
> snapshots during development.
>
> To me, this says that 2 is a major version and 10 is a minor version; so now
> I am confused about which is which
>
9/10 is the major version. 2 is the "epoch" i.e. the version of Scala
we are all using. It's similar to Python or Java. Python 3 is
incompatible in some profound ways with Python 2. If there will ever
be a Scala 3 it will be the same. Java's official version is 1.7, i.e.
1 is still the language version.

Cheers

-- Martin

Josh Suereth

unread,
Mar 16, 2012, 1:19:23 AM3/16/12
to scala-i...@googlegroups.com
Ok, my 2.9.x pull request is updated with the results of this thread.  Anyone want to take a look?

Francois

unread,
Apr 5, 2012, 9:50:40 AM4/5/12
to scala-i...@googlegroups.com, Josh Suereth
On 13/03/2012 13:37, Josh Suereth wrote:
> http://wiki.eclipse.org/Version_Numbering
>
>
> If you read the above document, you'll see how our version schemes are
> not cool for OSGi. In particular, we use our first number (2) to
> Denote the "era" of scala. Granted, their 'minor' version number
> distinction is pretty vague.
> [...]

Echoing the long thread that followed, I just saw that article:
http://www.infoq.com/news/2012/04/osgi-snapshot

Scala developpers seems to not be alone with their numbering pain...

Cheers,

--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com

Reply all
Reply to author
Forward
0 new messages