Comments on: Software Versioning is Ridiculous

By: Chris Aniszczyk

Chris Aniszczyk — Mon, 23 Nov 2009 14:54:24 +0000

@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

Richard Steele — Fri, 20 Nov 2009 02:22:01 +0000

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

Scott Stanchfield — Thu, 19 Nov 2009 22:00:27 +0000

@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

Scott Stanchfield — Thu, 19 Nov 2009 20:56:23 +0000

@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

Oisin Hurley — Thu, 19 Nov 2009 20:54:26 +0000

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: Carey

Carey — Thu, 19 Nov 2009 20:33:26 +0000

As far as I can tell, Linux version numbering has changed, and there will probably not be a version 2.7.anything. Two useless digits beats one for Java.

(I remember running successive versions of Linux 1.2.x, compiled myself. I had to quit X to have enough memory for GCC.)

By: Eugene Ostroukhov

Eugene Ostroukhov — Thu, 19 Nov 2009 20:22:26 +0000

Even if they used some “marketing” version strings on this dashboard it would not help. I think it would me more then enough to have two version strings – “latest” and “old”

In most cases users do not care about exact version. Versions are more important to technical staff – IT, plug-in developers, etc. Technical staff really enjoys clean and easy-to-compare “technical” version string.

By: Scott Stanchfield

Scott Stanchfield — Thu, 19 Nov 2009 19:06:18 +0000

Marketing vs. internal versions. I have had to fight so hard to get people to understand the difference. I can’t tell you how many times I’ve been forced to go back into code and change the version number that’s reported to match the marketing version. Sigh…

The only time the user cares about the actual version number is when there is a new version in a box on a shelf and they want to know if it’s different from the one they have. Of course that could be served by “better” “better still” “even better” “more superbly betterified” and “betterriffic”, which we all know are in ascending order of betteritude.

By: Scott Stanchfield

Scott Stanchfield — Thu, 19 Nov 2009 18:47:49 +0000

@David Carver
Actually, they broke backwards compatibility in 1.2.

If you had

import java.util.*;
import java.awt.*;

class Foo {
List list = new List();
}

It would compile fine in 1.1.x, but in 1.2.x, kaboom! Ambiguous import.
This is why Import On Demand Is Evil. (See http://javadude.com/articles/importondemandisevil.html)

– Scott

By: Kelly Campbell

Kelly Campbell — Thu, 19 Nov 2009 17:35:07 +0000

Here’s a unique one: TeX uses extended digits of pi. http://en.wikipedia.org/wiki/Software_versioning#TeX