[cvsnt] Re: Thoughts on version numbering

[Anthony Williams]

tmh at nodomain.org (Tony Hoyle) writes:

> I've been giving some thought to the version numbering system we have at the
> moment.
> 
> Originally it was planned to track the Unix CVS builds (cvsnt started out just
> as a patch to Unix CVS) so the numbering system was based around that ie.
> cvs verson 1.11.1 cvsnt version 3.  However time marches on and that's no
> longer true.  The 'build' system has basically taken over any version
> numbering anyway.
> 
> What I propose is that the numbering system is completerly revamped, so
> there's also some idea of 'stable' versioning too (I won't be maintaining too
> branches as I've tried that in the past and it doesn't scale, but there are
> definately points in the development where the product is more stable than
> others).
> 
> I can either start again 1.0 or leapfrog to 2.0.  I'd rather avoid numbers
> like 1.12 to minimise crossover with the Unix CVS version numbers.  I suggest
> something like <major release>.<stable version>.<patchlevel> and doing away
> with build numbers altogerther.  The idea is if a particular version is
> declare 'stable' (like the late 57 builds or as I hope the latest build is) I
> up the stable version and reset the patchlevel, so that everyone knows that
> that's the latest 'safe' install.  For this to happen to a release it should
> have no major or critical bugs filed against it for at least a week after
> release.
> 
> I'm really just brainstorming at the moment...  any input would be welcome.

I have been thinking for a while that the version numbering was a bit screwy
--- v1.11.1.3 build 76 sounds like it has exactly the same feature set as
build 1, but fewer bugs, whereas actually there are a lot more features.

Breaking away from "plain" CVS completely, and running from V2.0 seems like a
good idea. major.minor.patch seems a reasonable numbering scheme, with the
major/minor version incremented when you add new features, and the patch
incremented with bug fixes. You can then just label some releases as "stable".

However, there is also the problem that when you add new features these are
likely to be buggy, yet there might be fixes for bugs in other pre-existing
features. It seems awkward to have to upgrade to a new version, with new buggy
features which might impact other things too, just to get a fix for a bug in
another feature (though major software vendors do this to us all the time).

Consequently it would be nice to have say 2.0 and 2.1 run on separate
branches, with 2.1 containing new features, and the 2.0 branch restricted to
bug fixes. The decent branching support is one of the key benefits of CVS IMO
--- I just did a bugfix branch for a project using VSS the other day, and then
had to merge the changes back into the mainline; it is a *PAINFUL* process,
one file at a time, which took me all morning (only 300 files).

Labelling releases as "stable" seems like a good plan, too, so people who want
minimal hassle, but are willing to accept fewer features, can download (say)
2.0.9, whereas those who want the new features but accept that things might go
wrong every now and again can get 2.1.3.

Of course, there's then the issue of how many old versions to maintain
bugfixes for --- I can't believe that every bug in 2.0 will be fixed before
you've added new features that aren't in 2.1, and consequently released 2.2
(if you followed my suggested numbering scheme) given the rate at which
features seem to get added to CVSNT. I suppose that's why the major software
vendors just give up and say "you've got to upgrade to V8.2 if you want the
fix, despite the fact that you only need the features of V2.1" --- they can't
be bothered with the hassle of maintaining old releases, and forcing people to
upgrade is a revenue generator anyway.

Just my twopennorth

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.