Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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.