Comments on: Software Versioning is Ridiculous http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/ work. life. open source. diatribes. Mon, 14 May 2012 23:38:00 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Chris Aniszczyk http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-1490 Chris Aniszczyk Mon, 23 Nov 2009 14:54:24 +0000 http://aniszczyk.org/?p=1376#comment-1490 <a href="#comment-1484" rel="nofollow">@Richard Steele</a>, I disagree with your assertion around version numbers being arbitrary especially when it comes to module systems. <blockquote cite="#commentbody-1484"> <strong><a href="#comment-1484" rel="nofollow">Richard Steele</a> :</strong> <p>...Versions are arbitrary, as long as they can uniquely identify a specific release of the product...</p> </blockquote> Let me give you twos examples from OSGi land to think about. In OSGi, you can depend on different bundles using the <code>Require-Bundle</code> header. You can depend on ranges. Let's say you were writing an application that needed to use log4j. What version of log4j do you want to depend on? The first stab of your dependency can be written like this... <code>Require-Bundle: org.apache.log4j</code> You go to deploy your bundle on one system. It works, yay! You know go to deploy your bundle on some other system or someone else deploys your bundle... you get some crazy exceptions. It turns out, you were developing against log4j 1.1 and that worked great when deployed into the first system that was running 1.1... however... the second system your bundle was deployed to was running 1.2 and in version 1.2... the log4j team decided to break binary compatibility. Ok, you can now fix your bundle with this dependency statement: <code>Require-Bundle: org.apache.log4j;version=[1.1,1.2)</code> Now imagine that you needed commons collections? How should you depend on commons collections... what version ranges... what verison policy does the commons collections team follow? <code>Require-Bundle: org.apache.commons.collections;version=[2.1,3.0)</code> It turns out that commons collection 3.0 is binary compatible with 2.1... You see what I'm getting it? When there is no consistent set of versioning semantics when it comes to module systems... it's a world of pain. @Richard Steele, I disagree with your assertion around version numbers being arbitrary especially when it comes to module systems.

Richard Steele :

…Versions are arbitrary, as long as they can uniquely identify a specific release of the product…

Let me give you twos examples from OSGi land to think about. In OSGi, you can depend on different bundles using the Require-Bundle header. You can depend on ranges. Let’s say you were writing an application that needed to use log4j. What version of log4j do you want to depend on? The first stab of your dependency can be written like this…

Require-Bundle: org.apache.log4j

You go to deploy your bundle on one system. It works, yay!

You know go to deploy your bundle on some other system or someone else deploys your bundle… you get some crazy exceptions. It turns out, you were developing against log4j 1.1 and that worked great when deployed into the first system that was running 1.1… however… the second system your bundle was deployed to was running 1.2 and in version 1.2… the log4j team decided to break binary compatibility. Ok, you can now fix your bundle with this dependency statement:

Require-Bundle: org.apache.log4j;version=[1.1,1.2)

Now imagine that you needed commons collections? How should you depend on commons collections… what version ranges… what verison policy does the commons collections team follow?

Require-Bundle: org.apache.commons.collections;version=[2.1,3.0)

It turns out that commons collection 3.0 is binary compatible with 2.1…

You see what I’m getting it?

When there is no consistent set of versioning semantics when it comes to module systems… it’s a world of pain.

]]> By: Chris Aniszczyk http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-3162 Chris Aniszczyk Mon, 23 Nov 2009 14:54:00 +0000 http://aniszczyk.org/?p=1376#comment-3162 <a href="#comment-1484" rel="nofollow">@Richard Steele</a>, I disagree with your assertion around version numbers being arbitrary especially when it comes to module systems. <blockquote cite="#commentbody-1484"> <strong><a href="#comment-1484" rel="nofollow">Richard Steele</a> :</strong> ...Versions are arbitrary, as long as they can uniquely identify a specific release of the product... </blockquote> Let me give you twos examples from OSGi land to think about. In OSGi, you can depend on different bundles using the <code>Require-Bundle</code> header. You can depend on ranges. Let's say you were writing an application that needed to use log4j. What version of log4j do you want to depend on? The first stab of your dependency can be written like this... <code>Require-Bundle: org.apache.log4j</code> You go to deploy your bundle on one system. It works, yay! You know go to deploy your bundle on some other system or someone else deploys your bundle... you get some crazy exceptions. It turns out, you were developing against log4j 1.1 and that worked great when deployed into the first system that was running 1.1... however... the second system your bundle was deployed to was running 1.2 and in version 1.2... the log4j team decided to break binary compatibility. Ok, you can now fix your bundle with this dependency statement: <code>Require-Bundle: org.apache.log4j;version=[1.1,1.2)</code> Now imagine that you needed commons collections? How should you depend on commons collections... what version ranges... what verison policy does the commons collections team follow? <code>Require-Bundle: org.apache.commons.collections;version=[2.1,3.0)</code> It turns out that commons collection 3.0 is binary compatible with 2.1... You see what I'm getting it? When there is no consistent set of versioning semantics when it comes to module systems... it's a world of pain. @Richard Steele, I disagree with your assertion around version numbers being arbitrary especially when it comes to module systems.

Richard Steele :
…Versions are arbitrary, as long as they can uniquely identify a specific release of the product…

Let me give you twos examples from OSGi land to think about. In OSGi, you can depend on different bundles using the Require-Bundle header. You can depend on ranges. Let’s say you were writing an application that needed to use log4j. What version of log4j do you want to depend on? The first stab of your dependency can be written like this…

Require-Bundle: org.apache.log4j

You go to deploy your bundle on one system. It works, yay!

You know go to deploy your bundle on some other system or someone else deploys your bundle… you get some crazy exceptions. It turns out, you were developing against log4j 1.1 and that worked great when deployed into the first system that was running 1.1… however… the second system your bundle was deployed to was running 1.2 and in version 1.2… the log4j team decided to break binary compatibility. Ok, you can now fix your bundle with this dependency statement:

Require-Bundle: org.apache.log4j;version=[1.1,1.2)

Now imagine that you needed commons collections? How should you depend on commons collections… what version ranges… what verison policy does the commons collections team follow?

Require-Bundle: org.apache.commons.collections;version=[2.1,3.0)

It turns out that commons collection 3.0 is binary compatible with 2.1…

You see what I’m getting it?

When there is no consistent set of versioning semantics when it comes to module systems… it’s a world of pain.

]]> By: Richard Steele http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-1484 Richard Steele Fri, 20 Nov 2009 02:22:01 +0000 http://aniszczyk.org/?p=1376#comment-1484 While I agree that this does seem to cause problems, in my experience it's as much a "techno-political" issue than anything else. Versions are arbitrary, as long as they can uniquely identify a specific release of the product. Don't forget another important reason for version numbers: support. "What version are you running, and what version of the OS are you running it on?" are very often the first questions we need answered to address a support call. While I agree that this does seem to cause problems, in my experience it’s as much a “techno-political” issue than anything else. Versions are arbitrary, as long as they can uniquely identify a specific release of the product. Don’t forget another important reason for version numbers: support. “What version are you running, and what version of the OS are you running it on?” are very often the first questions we need answered to address a support call.

]]> By: Richard Steele http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-3161 Richard Steele Fri, 20 Nov 2009 02:22:00 +0000 http://aniszczyk.org/?p=1376#comment-3161 While I agree that this does seem to cause problems, in my experience it's as much a "techno-political" issue than anything else. Versions are arbitrary, as long as they can uniquely identify a specific release of the product. Don't forget another important reason for version numbers: support. "What version are you running, and what version of the OS are you running it on?" are very often the first questions we need answered to address a support call. While I agree that this does seem to cause problems, in my experience it’s as much a “techno-political” issue than anything else. Versions are arbitrary, as long as they can uniquely identify a specific release of the product. Don’t forget another important reason for version numbers: support. “What version are you running, and what version of the OS are you running it on?” are very often the first questions we need answered to address a support call.

]]> By: Scott Stanchfield http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-1483 Scott Stanchfield Thu, 19 Nov 2009 22:00:27 +0000 http://aniszczyk.org/?p=1376#comment-1483 <a href="#comment-1481" rel="nofollow">@oisin </a> <blockquote cite="#commentbody-1481"> 5) you’re going to have to re-write your code, sorry, by the way we have a new training course.</blockquote> Hehehe... I bet that was a great driver for the marketing team to up the version numbers artificially... @oisin

5) you’re going to have to re-write your code, sorry, by the way we have a new training course.

Hehehe… I bet that was a great driver for the marketing team to up the version numbers artificially…

]]> By: Scott Stanchfield http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-3160 Scott Stanchfield Thu, 19 Nov 2009 22:00:00 +0000 http://aniszczyk.org/?p=1376#comment-3160 <a href="#comment-1481" rel="nofollow">@oisin </a> <blockquote cite="#commentbody-1481"> 5) you’re going to have to re-write your code, sorry, by the way we have a new training course.</blockquote> Hehehe... I bet that was a great driver for the marketing team to up the version numbers artificially... @oisin

5) you’re going to have to re-write your code, sorry, by the way we have a new training course.

Hehehe… I bet that was a great driver for the marketing team to up the version numbers artificially…

]]> By: Scott Stanchfield http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-1482 Scott Stanchfield Thu, 19 Nov 2009 20:56:23 +0000 http://aniszczyk.org/?p=1376#comment-1482 <a href="#comment-1479" rel="nofollow">@Eugene Ostroukhov </a> I agree - latest/old would work great when you're in an update manager. Won't work so well on a box at the store though ;) @Eugene Ostroukhov
I agree – latest/old would work great when you’re in an update manager. Won’t work so well on a box at the store though ;)

]]> By: Scott Stanchfield http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-3159 Scott Stanchfield Thu, 19 Nov 2009 20:56:00 +0000 http://aniszczyk.org/?p=1376#comment-3159 <a href="#comment-1479" rel="nofollow">@Eugene Ostroukhov </a> I agree - latest/old would work great when you're in an update manager. Won't work so well on a box at the store though ;) @Eugene Ostroukhov
I agree – latest/old would work great when you’re in an update manager. Won’t work so well on a box at the store though ;)

]]> By: Oisin Hurley http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-1481 Oisin Hurley Thu, 19 Nov 2009 20:54:26 +0000 http://aniszczyk.org/?p=1376#comment-1481 Marketing is the major driver for a 'public' version number in most cases. You get some interesting stories - for example, at one point our (now ex-) marketing team decided that products with a major version "4" were bad luck. So we had products go from 3.1 straight to 5.0 (which basically allows you to break binary compatibility twice!). People who don't care so much about that side of things have fun instead - like the π incident and negative range numbers. There's also plain old intransigence like the silly Scala 2.7 vs 2.8 affair. @Scott - I've seen that happen sooo many times. I've always used version to tell a story - basically how hosed you are going to be once you upgrade. This ranges from 0) drop-in replacement; 1) we've changed some third-party stuff; 2) you're going to have to re-write your scripts; 3) you're going to have to re-link all your binaries, sorry; 4) you're going to have to recompile everything, sorry; 5) you're going to have to re-write your code, sorry, by the way we have a new training course. Marketing is the major driver for a ‘public’ version number in most cases. You get some interesting stories – for example, at one point our (now ex-) marketing team decided that products with a major version “4″ were bad luck. So we had products go from 3.1 straight to 5.0 (which basically allows you to break binary compatibility twice!). People who don’t care so much about that side of things have fun instead – like the π incident and negative range numbers. There’s also plain old intransigence like the silly Scala 2.7 vs 2.8 affair.

@Scott – I’ve seen that happen sooo many times. I’ve always used version to tell a story – basically how hosed you are going to be once you upgrade. This ranges from 0) drop-in replacement; 1) we’ve changed some third-party stuff; 2) you’re going to have to re-write your scripts; 3) you’re going to have to re-link all your binaries, sorry; 4) you’re going to have to recompile everything, sorry; 5) you’re going to have to re-write your code, sorry, by the way we have a new training course.

]]> By: Oisin Hurley http://aniszczyk.org/2009/11/19/software-versioning-is-ridiculous/comment-page-1/#comment-3158 Oisin Hurley Thu, 19 Nov 2009 20:54:00 +0000 http://aniszczyk.org/?p=1376#comment-3158 Marketing is the major driver for a 'public' version number in most cases. You get some interesting stories - for example, at one point our (now ex-) marketing team decided that products with a major version "4" were bad luck. So we had products go from 3.1 straight to 5.0 (which basically allows you to break binary compatibility twice!). People who don't care so much about that side of things have fun instead - like the π incident and negative range numbers. There's also plain old intransigence like the silly Scala 2.7 vs 2.8 affair. @Scott - I've seen that happen sooo many times. I've always used version to tell a story - basically how hosed you are going to be once you upgrade. This ranges from 0) drop-in replacement; 1) we've changed some third-party stuff; 2) you're going to have to re-write your scripts; 3) you're going to have to re-link all your binaries, sorry; 4) you're going to have to recompile everything, sorry; 5) you're going to have to re-write your code, sorry, by the way we have a new training course. Marketing is the major driver for a ‘public’ version number in most cases. You get some interesting stories – for example, at one point our (now ex-) marketing team decided that products with a major version “4″ were bad luck. So we had products go from 3.1 straight to 5.0 (which basically allows you to break binary compatibility twice!). People who don’t care so much about that side of things have fun instead – like the π incident and negative range numbers. There’s also plain old intransigence like the silly Scala 2.7 vs 2.8 affair.

@Scott – I’ve seen that happen sooo many times. I’ve always used version to tell a story – basically how hosed you are going to be once you upgrade. This ranges from 0) drop-in replacement; 1) we’ve changed some third-party stuff; 2) you’re going to have to re-write your scripts; 3) you’re going to have to re-link all your binaries, sorry; 4) you’re going to have to recompile everything, sorry; 5) you’re going to have to re-write your code, sorry, by the way we have a new training course.

]]>