Friday, May 30, 2008

Is 9903520300447984150353281023 Too Small?

JSR 277's Stanley Ho published a rationale why (in the so far unpublished EDR2) JAva Modules (JAM) invent a brand new version scheme. A rationale that needs a lot of text. I could go in painstaking detail, but I think the rationale derails in one of the first paragraphs where the requirements are (implicitly) described. I highlighted the part that describes in what kind of situations you use the major, minor, micro, update, and qualifier version parts:
  • Major version number should be incremented for making changes that are not backward-compatible. The minor and the micro numbers should then be reset to zero and the update number omitted.
  • Minor version number should be incremented for making medium or minor changes where the software remains largely backward-compatible (although minor incompatibilities might be possible); the micro number should then be reset to zero and the update number omitted.
  • Micro version number should be incremented for changing implementation details where the software remains largely backward compatible (although minor incompatibilities might be possible); the update number should then be omitted.
  • Update version number should be incremented for adding bug fixes or performance improvements in a highly compatible fashion.
  • Qualifier should be changed when the build number or milestone is changed.

Can you spot the difference between minor and micro? I can't, and that is the reason that OSGi proposes the following convention: incompatible (major), backward compatible (minor), no API change/bugfix (micro), and builds or variations (qualifier). That is, our micro is Sun's update because Sun's minor and micro appear to have an identical purpose.

And ever thought about the concept of largely backward compatible? Isn't that something like a little bit pregnant?

There are always reason to improve on existing schemes, but any improvement should be balanced against the interests of the existing and future audiences. I am not stating that the OSGi version is the mother of all version schemes, we are as fallible as all of us. Maybe we were too rationalistic; we looked at a lot of schemes and saw how people were also looking for more room at the low-end of the version scheme and hardly ever incremented the first numbers. If you standardize there is always a tension between allowing as much freedom as possible but also minimizing the complexity of the implementations that are depending on the variations you offer. We chose simplicity.

Is the OSGi scheme usable? Well, we have no outstanding requirements or bugs in this area, nor were any proposed in JSR 291, while at the same time it is heavily used. Jason van Zyl, Maven, told me they were thinking of adopting the scheme as well. SpringSource converted almost 400 open source projects to bundles and they did not complain. Seems there is a lot of practical usage out there.

Wouldn't it be a lot more productive for all of us if Sun would just adopt the OSGi scheme? There is lots of work to do on the module API, why not reuse existing specifications where you can? And if the OSGi scheme has burning issues, why not report that as a bug or change request, after all Sun is a distinguished OSGi member.

With an infinite number of builds or variations, 9903520300447984150353281023 possible bug fixes (80.000 fixes per microsecond until the Sun implodes), 4611686014132420609 backward compatible changes, and 2147483647 incompatible releases, the OSGi spec seems to have enough room to breathe for mere mortals.

Peter Kriens

P.S. You did register for the OSGi Community Event in Berlin, June 10-11? Please do so, we have a very strong program prepared with lots of cool demos. Hope to see you there!


  1. I believe you've missed the key part of Stanley Ho's rationale: "The JDK uses four numbers like 1.2.2_18 or 1.4.2_16 because of its longstanding practice that the major version is 1.". Everything else is irrelevant.

  2. Stanley's post was an attempt to rebut the points I made:

  3. elizarov: Yes you are right. I humble apologize and suggest we from now on mandate that all version numbers start with 1. Hmm. so we can solve the incompatibility. If the major part is always one, we have only 3 parts left and they map perfectly to the OSGi scheme!

    Peter Kriens

  4. Alex: Yes, should have included the link, thanks. Was a nice post btw.

    Peter Kriens

  5. Nice post from both of you (Alex and Peter). Actually I still can't understand why people don't understand the importance of version numbers in component systems! The statement "largely backward-compatible (although minor incompatibilities might be possible)" is an absolute no go in my opinion! We finally arrived at a point, where we are able to automatically deal with different and potentially incompatible versions of our components. And now? The “great” NEW system is supposed to destroy all of our achievements so fare? What's the point? I honestly can't find any rational behind this. Somehow it feels like versioning is again nothing more than a marketing term - useless for real software development. It is just sad!

    Actually I was working on a system to determine the correct version number of the latest version of the API for a bundle (in a syntactic and semantic way). With this it would be guaranteed, that version ranges can always be applied correctly, without having the human factor causing problems - components, you can actually trust. But I guess, I can just relax and write a random number generator. That’ll be as reliable as the new versioning scheme. Sorry, but sometimes only sarcasm helps.


  6. No se esta inventando Microsoft .Net lo usa, Java mismo lo Usa no es fundamentado su comentario y no he una invención es el estándar de los grandes no creo que tener cuatro números nos afecte. Es que siempre vemos lo que ya esta hecho y decimos que es perfecto (OSGi) y no queremos cambiarlo como informáticos debemos de saber que todo tiene cosas buenas y malas y en mi caso veo el sistema de versiones de tres números simplista y no adaptado a los sistemas de versiones utilizados por la industria y la industria no es solo Java.


Blog Archive