Re: [Rosegarden-devel] version numbers -- pick one

[D. M. M. <ros...@gm...>]

On Thursday 16 April 2009, Matthew Woehlke wrote:

> Or maybe we need better elementary school teachers :-). 10 comes after
> 9. (And in the real world, it isn't always practical to bump the next
> level of version when you hit 9. If version 0.9 is nowhere near "1.0",
> and neither is the next version, calling it thus really isn't
> appropriate if the version number is to mean anything.)

The problem, for example, is which is greater, Matthew, 0.7 or 0.23?

Right.  0.7 is clearly greater than 0.23, so standard version check code to 
see if version is greater than or equal to 0.7 says that 0.23 is too old.  
But 0.23 is actually the new one, and if this library had had a sensible 
versioning scheme, it would have been a comparison between 0.0.7 and 0.2.3, 
or 0.7 and 2.3.  That is what the respective numbers in this case really do 
represent after all.

Sure, there's a KDE 3.5.10 which is greater than KDE 3.5.1, but that never 
confuses anyone because 10 is greater than 1 and both numbers are in the 
same "place" in the scheme.  One could argue that the 0.7 and 0.23 are no 
different, and they're both in the same "place" in the scheme too, only there 
is no intervening number between them, so the whole thing could be expressed 
as 0.0.7 and 0.0.23 as well, and it's no different.

But it is different on the ground, and the difference is the level of 
confusion it causes in practice, which is expressed in the number of "I can't 
build Rosegarden because I only have version 0.23, and I can't find a copy of 
newer version 0.7 anywhere."

This particular issue has mostly been dealt with, but it's a real example of 
the sort of shenanigans we want to avoid.

As far as that goes, the official working resolution to this whole debate as 
of now is Rosegarden 09.x, where .x will be whatever month we finally release 
something in.

I've grown weary of the .x since we took that position by democratic vote, and 
I think I'm going to discard the result of the vote and go with 09.1 09.2 
09.3 after all, with the working future revision number for the eventual 
release of the current development line of code being 09.1 whenever it 
happens to come out.  (Unless that's not until 2010, which is too hard to 
call at this point.  I hope not, but I definitely wouldn't even try to guess 
what month in '09 this might actually release.)

> Aaaaaaand you're going to add a third number when needed, yes?)

It isn't likely we'd ever need a third number in practice.  Especially if we 
just use sequential "within the year" numbers.
-- 
D. Michael McIntyre