Alex has posted 1 posts at DZone. View Full User Profile

Version Numbers and JSR277

05.23.2008
| 4295 views |
  • submit to reddit

Although I've written recently that it looks like OSGi and JSR277 are coming together, there are still a number of things that are potential concrete blocks on the road to progress. This information is based on the public draft from 2006 so it's possible that some detail has changed; but reading between the lines on the various JSR277 blogs, it doesn't seem to be the case.

The first concerns the format of the version number. Why Sun, of all people, should be in charge of version formats is beyond me; they've invented a new versioning system for pretty much each version of Java that came out (JDK 1.0.2, JRE/JDK 1.1.8_010, J2RE/J2SDK 1.2.2_17, J2RE/J2SDK 1.3.1_21, J2RE/J2SDK 1.4.2_16, JDK/JRE 5.0 Update 14, JDK/JavaSE 6 Update 6 with NetBeans, and who could forget Java SE 6 Update 10 aka Update N aka 6uN). Oh, and of course they've changed all the URLs, so whilst you used to be able to browse for java.lang.Object, you now get redirected to a faceless JavaSE page which doesn't have any references to what it used to point to. Way to go, Sun.

The second concerns the number of numbers. The version numbering format for a JSR277 module is major.minor.micro.update-qualifier. The first four are numeric (defaulting to zero if missing) and the qualifier is textual. According to the documentation of 2006, the qualifier must be used for beta releases, and must not be used for released versions. In fact, the empty string for qualifier is deemed greater than any other value. Quite aside from that, who uses four version numbers, anyway? Basically Oracle (hey, wow; they're now on to five digits - Oracle Database 11g Release 1 (11.1.0.6.0) is the current version of Oracle 11g) and Sun (java -version gives java version "1.5.0_13"). Note how many of those digits are zero and basically unused; also note how many of them are still carrying around excess baggage of versions. All Java versions have started with a 1, so that's one digit burnt up already; and the third digit is basically used occasionally to mark the number of builds. But get this - the Java builds have incremental feature, so that zero isn't used anymore either. In a few passing versions of Java, they used it to reset the build count, but back in the really early days, they used the fourth number (e.g. 1.1.8_005, 1.1.8_006, 1.1.8_007, 1.1.8_008) to hide the fact that it was as buggy as hell, and they didn't want to show to the outside world how many releases they had made. The same followed through into Java 1.4 (1.4.0_0 to 1.4.0_4, 1.4.1_0 to 1.4.1_07, 1.4.2_0 to 1.4.2_16). The whole rationale for the last number was purely a (failed) marketing exercise, much like the remainder of the Java versioning saga. Am I the only person who is reminded of the The Onion's story on ever-increasing numbers of razor blades (which presaged this by two years, although it's worth noting their incompetence extends to their home page ... but I digress)

The third concern is the range specification for version numbers. Most modules will, at some point, want to depend on a specific version or range of versions. There's a choice here; re-use well understood versioning or invent your own mechanism. But hey, if you're re-inventing module systems, why not re-invent your own versioning format too? As a result, we're left with an utterly bizarre notation for representing ranges. Thus is born:

Open range
An open range is defined as greater than or equal to a specified version, giving us:
  • 1+ anything 1.0.0.0 or above
  • 1.1+ anything 1.1.0.0 or above (c.f. other digits)
Family range
A family range is defined as greater than or equal to a specified version, but not going above the ceiling, giving us:
  • 1* anything 1.0.0.0 or above but below 2.0.0.0
  • 1.1* anything 1.1.0.0 or above but below 1.2.0.0 (c.f. other digits)
Open range within fammily
A combination of the two allowing for some utterly bizzare twists, giving us:
  • 1.[1.1.1+] anything 1.1.1.1 or above but below 2.0.0.0
  • 1.1.[1.1+] anything 1.1.1.1 or above but below 1.2.0.0 (c.f. other digits)
Union of open ranges within fammily
Seeing as it's impossible to represent constraints of anything above +1, you need to be able to combine them:
  • 1.[2.3.4+];2*;3* anything 1.2.3.4 or above but below 4.0.0.0
  • 1.1.[1.1+];3* anything 1.1.1.1 or above but below 1.2.0.0, or those between 3.0.0.0 (inclusive) and 4.0.0.0 (exclusive)

Frankly, it will be amazing if anyone gets their version numbers right in their metadata. When to use * or +? When to have a different digit? Who knows. And how are they going to map onto a versioning system which uses less digits?

Now, compare that with OSGi's version numbering scheme:

  • Three numeric and one string qualifier
  • Versions can be open "1.2.3" or a range "[1.2.3,4.5.6)", technically allowing both inclusive and exclusive start/end points (but usually having an inclusive start and an exclusive end, defaulting to infinity)

That's it. No other complications. Easy to define a version that must be greater than 1.2.3 and less than 4.5.6 (sub-versions are optional and default to zero). No restrictions on what you can use the qualifier for, or when to use it. No extra digits (OSGi went through the learning pain of getting it right the first time; learning from other people's mistakes is the art of true genius).

True, it means that you can't do things like five version numbers in OSGi, but that's not a problem, that's a feature. Look at most of the OSGi bundles around you - you can bet that at least one, possibly two of the version numbers are being consumed with some variant of the product number. Eclipse has started to move away from that somewhat, so in the recent 3.4 builds you'll still find bundles that are prefixed with 3.1; but it's still burning up two version numbers to get to that point (with the result that people are trying to cram in extra precision in the single last version number).

Module versioning is like playing the piano. The problem isn't how many digits you've got, it's using them effectively.

Original article http://alblue.blogspot.com/2008/05/version-numbers-and-jsr277.html

 

Published at DZone with permission of its author, Alex Blewitt.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Emmanuel Bourg replied on Fri, 2008/05/23 - 11:50am

Quite aside from that, who uses four version numbers, anyway?

Firefox, Thunderbird, Filezilla, Azureus...

Richard D. Jackson replied on Fri, 2008/05/23 - 10:47pm

I don't know the version system sun seems to have come up with sounds reasonable to me (as you have explained it). Currently where I work we also use a 4 number version like so:

Position 1 - Major version number (meets defined use case)

Position 2 - Minor version (Can mean that some external interface has changed but still meets the use case requirements of the major version. For instance in the case that some external resource changes such that we had to change the way something works but the design still meets the major version use case)

Position 3 - This is similar to minor version but nothing external facing changed. But it was a re-factoring or some such.

Position 4 - Bug fix

So Yes I can see the need to do 1.1* meaning that I know for our internal stuff at least that I can depend on that. But I can not depend on 1* with out evaluating it.

The last place I worked at also used a 4 number version as well. So I can understand why Sun would want to support that.

Chris Clark replied on Sun, 2008/05/25 - 10:26pm

I agree about the versioning scenario

"Why Sun, of all people, should be in charge of version formats is beyond me"

True, look at the versioning blight of Solaris - I had a lot of grief understanding what version of Solaris was running on production systems at my work.

Then, look at the Java versioning - once it was 1.1, then was 1.2 (but also J2SE), then 1.3, 1.4 and now 5.0 and 6.0 - the blight of Solaris has moved to JDK versioning (ewww)

I was always one who thought of versioning/build/release as three separate items, but all had one common denominator.

Version is:

major.minor.micro (3 separate numeric identifiers) - and I do understand that some people misread this, so let me make it clear: non-zero based - so not 099, but 99. Leading zeros in versioning create a lot of confusion. This has also been an issue in the open source community.

<edit>
Some people will misunderstand this, but sometimes m.j.015 is misrepresented as m.j.15, and therefore m.j.151 is used as a new micro release instead of m.j.16 (but this can generally be a problem in the OSC of using major/minor combinations without the micro - anyway, I believe that if there is a confusion regarding micro versioning, it should be resolved and the micro updated (in the case that it is a specific micro that has been accepted previously for production - then the micro will be updated, build will of course always change).
</edit>

release is:

alpha / beta / rc (release candidate) / final (production release) / maintenance

build is:

an integer number that represents a common build that is publicly released (i.e. 1057) - the build number is commensurate with a major.minor combination - i.e. version 1.1.* build 2048 is not the same as 1.2.* build 2048.

I leave it up to the community, but personally I believe that build/version/release should be separate, and standardized (especially version and release)

Very interested to hear what fellow Java Lobby members feel about this :-)

BTW - IM enjoying the new JavaScript editor for posting comments (an old fuddy duddy that has been away for a while). It is being used in my company for our own internal wikis.

 

Chris Clark replied on Sun, 2008/05/25 - 10:57pm in response to: Chris Clark

And just, as an additional note, the major should not be updated unless there is a significant change in functionality, or a major rewrite. Hopping between major versions is something that (while mostly in retrospect) can create version dead-end - like with MacOS. Mac OS suffered from its outset (yes, I worked on early Macs in the mid 90s) from the same versioning issue.

I Suppose the same issue is with Final Fantasy (X release onwards) - once you reach major 10, then it has to be a major rewrite, and a new label. Final Fantasy could not afford the relabelling, but Mac OS did, and created Mac OS X. The only thing is now.... JavaNG? Java X? or JDK7 1.0.0  

Jesper Nordenberg replied on Mon, 2008/05/26 - 5:54am

Ah, another version number debate... :-)

In a system where software modules link to other modules by dynamic reference, each digit in a version number must have a fixed meaning. All modules must follow the same versioning rules otherwise the system will break. IMO, 3 digits is usually enough:

  • major - an increase in major version means a break in backwards compatibility, external modules which work against version 1.x.x are not expected to work against 2.x.x
  • minor - major changes has been performed (new functionality added, major rewrite of implementation), external modules who worked with previous version are expected to work with the new version (of course, there is some room for interpretation, for example JRE 1.5 is not 100% compatible with 1.4)
  • patch - increased for each new release unless major or minor is increased, typically small bug fixes

 

I don't know how to handle alpha, beta and RC effectively without additional information attached to the version number.

Mark Thornton replied on Tue, 2008/05/27 - 4:12am

The proposed version number scheme and patterns seems almost identical to that which has been in use in JNLP for some time. The [] syntax is the only bit I don't recall seeing before. To propose something that was not an extension of the JNLP scheme would be perverse.

Johan Zahri replied on Tue, 2008/05/27 - 12:17pm in response to: Richard D. Jackson

Richard,

I like 4 version numbers scheme.

I'd prefer the bug fix be in the third position though rathar than the 4th.

The 4th would be things that doesn't concern the user's point of view but concerns the development teams point of view, those things like refactorings et al.

 

Regards,

Johan 

Alex Blewitt replied on Mon, 2008/06/02 - 5:04am

I've posted a follow-up to my original article, rebutting the points made re: Firefox/Oracle. A component system needs to track the versions of components, which are orthogonal to the name or numbers associated with an overall product. You can read more at: 

http://alblue.blogspot.com/2008/06/components-products-and-fragile.html

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.