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.
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. Tony