Reinier Zwitserloot :

Now, which part of that argument is ‘ridiculous’ and ‘terrible’? I might be overestimating the amount of version fail that’s going to occur, but you can’t deny accidents happen.

My biggest problem was that Sun hasn’t really reached out to the OSGi community for help in building a module system. They just came down from the mountains with their solution. However, that’s a topic of another post. Also, I thought people would be a bit more thick-skinned by now working in open source.

My point is that versioning is critical to module systems and they can’t just be an afterthought. Having a consistent version scheme so you can express contracts is mandatory. Just look at the versioning landscape in Java… it’s a mess. I would just like to clean things up given a chance.

However, this still doesn’t give us any consistent semantics about versions… it would be up to the decision of each bundle supplier how to treat their version values. It’s a step forward, but I think we would all be doing ourselves a favor if we just chose a reasonable versioning scheme and stuck with it. What do we really get out of coming up with version numbers for our components? A chance to express some creativity? Ideally, I would love to have it happen automatically for us based on changes in the code.

Jannick :
Couldn’t this issue be resolved by having the commons 3.0 module meta-data include a binary-compatible-replacement-off-versions:

This discussion wouldn’t be complete without this tidbit from Peter Kriens:

“… I believe life would have been easier if we would have had export ranges because the exporter of a package knows exactly to which version he is compatible, being the responsible person for that package. If he changes a package, he is the one thinking and deciding about backward compatibility. The importer is almost always guessing. That is, if I make a change to a package called p, I can knowingly say that I am package p version 2, but I am completely compatible to version 1 I therefore can export p;[1,2]. In contrast, if I import package p I have no clue if version 1 and 2 will be compatible except for the convention of version number interpretation. Alas, export versions did not make it to R4.”

http://www.osgi.org/blog/2008/02/research-challenges-for-osgi.html

Miroslav Pokorny :
[...] I believe a “i-am-backward-compatible-with” would help.[...]

I think you hit the nail on its head. The issue of specifying version ranges at import time just delegates the problem.

Chris, you had some very good examples in your blog. But in all cases it was *never* the clients fault. In all examples the producers just didn’t get the versioning right. It really is the task of a producer to decide which versions they want to be compatible to. This should be as dead easy as declaring it at export time, i.e. a package export should say “hey, I’m version 3.0 and I’m binary compatible to 2.1, 2.2 and whatever was out there before, if not my module vendor screwed up”.

A debatable issue, to be sure. There’s a third way out, of course: Enforcing that marketing no longer decides versions. If you think you can enforce this across the entire java community, you’re delusional.

So, two fairly legitimate strategies. I have a slight preference for OSGi’s model over sun’s choice, but, eh. Sun wants to be compatible with stuff like debian, which already has semantic meanings for this stuff, and it’s somewhat different to the OSGi model, so I get where they are coming from.

And yet you start ranting like a crazy man – calling it ‘ridiculous’ and ‘terrible’. You’re not doing OSGi any favours by acting this way.

FYI, jigsaw allows a similar version bounding scheme as OSGi. jigsaw splits the version string into pieces along punctuation (dots and dashes), and per block you can specify bounds, including numeric ones, so [1.1, 1.2) has similar meaning. The problem is of course that you have to check the exact meaning of each level of number per module, but you yourself said that log4j broke backwards compatibility by accident. They would release the wrong version. Version systems suck unless a given version release is never ever changed, so once log4j released this wrongly labelled version, you’re stuck with it forever.

Pragmatically speaking, then, this much celebrated intrinsic meaning of version numbers is a guideline at best. Add in projects throwing documentation to the wind and going with their own versioning schemes because marketing said so, and the OSGi situation isn’t all that much different from jigsaw’s proposals, except that jigsaw’s proposal is far more flexible.

Now, which part of that argument is ‘ridiculous’ and ‘terrible’? I might be overestimating the amount of version fail that’s going to occur, but you can’t deny accidents happen.

NB: Regarding take-backsies on misversioned stuff, jigsaw’s plan is for (module-name+version, jar*) tuples to be stored in a central repository on the local machine, so with that plan, taking back a released version to reversion it is just not feasible.

*) It won’t be a jar, but some other file format, but I doubt this is a relevant detail.