Comments on: Jigsaw Versioning is Ridiculous http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/ work. life. open source. diatribes. Fri, 03 Feb 2012 17:01:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Is there a future for software versioning? | All the small things http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1530 Is there a future for software versioning? | All the small things Tue, 15 Dec 2009 00:56:20 +0000 http://aniszczyk.org/?p=1494#comment-1530 [...] Chris Aniszczyk: http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/ [...] [...] Chris Aniszczyk: http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/ [...]

]]> By: Alex Buckley http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1892 Alex Buckley Thu, 03 Dec 2009 04:22:43 +0000 http://aniszczyk.org/?p=1494#comment-1892 The design and implementation of the Jigsaw module system is carried out in OpenJDK's Project Jigsaw. The project's mailing list would have been an excellent place to comment on the Jigsaw version scheme. Unfortunately, there has been very little activity in the OpenJDK project by members of the OSGi community. This may be because the goals of the Jigsaw module system are very different to the goals of the OSGi module system, as Sun has documented in recent public presentations (Strange Loop 2009, Devoxx 2009). The design and implementation of the Jigsaw module system is carried out in OpenJDK's Project Jigsaw. The project's mailing list would have been an excellent place to comment on the Jigsaw version scheme. Unfortunately, there has been very little activity in the OpenJDK project by members of the OSGi community. This may be because the goals of the Jigsaw module system are very different to the goals of the OSGi module system, as Sun has documented in recent public presentations (Strange Loop 2009, Devoxx 2009).

]]> By: Alex Buckley http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1893 Alex Buckley Thu, 03 Dec 2009 03:21:29 +0000 http://aniszczyk.org/?p=1494#comment-1893 The Jigsaw version scheme is very similar to OmniVersion. The OmniVersion link has very little to say on semantics; the meaning of individual segments is deferred to the underlying system (Mozilla, RedHat, Apache...). The OmniVersion comparator assumes structured input of arbitrary length, just like the Jigsaw comparator. The Jigsaw version scheme is very similar to OmniVersion. The OmniVersion link has very little to say on semantics; the meaning of individual segments is deferred to the underlying system (Mozilla, RedHat, Apache…). The OmniVersion comparator assumes structured input of arbitrary length, just like the Jigsaw comparator.

]]> By: Alex Buckley http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1518 Alex Buckley Wed, 02 Dec 2009 21:22:43 +0000 http://aniszczyk.org/?p=1494#comment-1518 The design and implementation of the Jigsaw module system is carried out in OpenJDK's Project Jigsaw. The project's mailing list would have been an excellent place to comment on the Jigsaw version scheme. Unfortunately, there has been very little activity in the OpenJDK project by members of the OSGi community. This may be because the goals of the Jigsaw module system are very different to the goals of the OSGi module system, as Sun has documented in recent public presentations (Strange Loop 2009, Devoxx 2009). The design and implementation of the Jigsaw module system is carried out in OpenJDK's Project Jigsaw. The project's mailing list would have been an excellent place to comment on the Jigsaw version scheme. Unfortunately, there has been very little activity in the OpenJDK project by members of the OSGi community. This may be because the goals of the Jigsaw module system are very different to the goals of the OSGi module system, as Sun has documented in recent public presentations (Strange Loop 2009, Devoxx 2009).

]]> By: Alex Buckley http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1517 Alex Buckley Wed, 02 Dec 2009 20:21:29 +0000 http://aniszczyk.org/?p=1494#comment-1517 The Jigsaw version scheme is very similar to OmniVersion. The OmniVersion link has very little to say on semantics; the meaning of individual segments is deferred to the underlying system (Mozilla, RedHat, Apache...). The OmniVersion comparator assumes structured input of arbitrary length, just like the Jigsaw comparator. The Jigsaw version scheme is very similar to OmniVersion. The OmniVersion link has very little to say on semantics; the meaning of individual segments is deferred to the underlying system (Mozilla, RedHat, Apache…). The OmniVersion comparator assumes structured input of arbitrary length, just like the Jigsaw comparator.

]]> By: Chris Aniszczyk http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1506 Chris Aniszczyk Tue, 24 Nov 2009 16:01:42 +0000 http://aniszczyk.org/?p=1494#comment-1506 <blockquote cite="#commentbody-1500"> <strong><a href="#comment-1500" rel="nofollow">Reinier Zwitserloot</a> :</strong> <p>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.</p> </blockquote> 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.

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.

]]> By: Chris Aniszczyk http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-3176 Chris Aniszczyk Tue, 24 Nov 2009 16:01:00 +0000 http://aniszczyk.org/?p=1494#comment-3176 <blockquote cite="#commentbody-1500"> <strong><a href="#comment-1500" rel="nofollow">Reinier Zwitserloot</a> :</strong> 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. </blockquote> 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.

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.

]]> By: Chris Aniszczyk http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1505 Chris Aniszczyk Tue, 24 Nov 2009 15:54:25 +0000 http://aniszczyk.org/?p=1494#comment-1505 Yes, I think that this would have been easier if we had export ranges or some other metadata in the MANIFEST.MF indicating binary compatibility. 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. Yes, I think that this would have been easier if we had export ranges or some other metadata in the MANIFEST.MF indicating binary compatibility.

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.

]]> By: Chris Aniszczyk http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-3175 Chris Aniszczyk Tue, 24 Nov 2009 15:54:00 +0000 http://aniszczyk.org/?p=1494#comment-3175 Yes, I think that this would have been easier if we had export ranges or some other metadata in the MANIFEST.MF indicating binary compatibility. 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. Yes, I think that this would have been easier if we had export ranges or some other metadata in the MANIFEST.MF indicating binary compatibility.

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.

]]> By: Luke Patterson http://aniszczyk.org/2009/11/23/jigsaw-versioning-is-ridiculous/comment-page-1/#comment-1504 Luke Patterson Tue, 24 Nov 2009 14:06:19 +0000 http://aniszczyk.org/?p=1494#comment-1504 <blockquote cite="#commentbody-1494"> <strong><a href="#comment-1494" rel="nofollow">Jannick</a> :</strong> Couldn’t this issue be resolved by having the commons 3.0 module meta-data include a binary-compatible-replacement-off-versions: </blockquote> 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

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

]]>