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.
Gabriel Genellina, > May I suggest using more "separate" version numbers? > For an outsider, 2.5.03 and 2.5.04 appear to be essentially the same > version, just with small bugs fixed. And a number like 2.6 means "new > features" not present in 2.5. At least that's what I would > expect without knowing the CVSNT history. This should be in the FAQ - we've followed this pattern years now... The version number is V.NN.XX.BBBB V = major architecture changes NN = significant architecture changes XX = feature releases BBBB = bug fixes Note: from 2005 'zero' is no longer considered a valid number (ie: EVS is 3.1 not 3.0) Eg: 1.11 to 2.0 major architecture changes, eg: ditching C for C++ 2.x to 3.1 major architecture changes, eg: ditching RCS for Relational DB. 2.5 to 2.8 significant architecture changes, eg: ditching cvsservice/xinetd 2.0 to 2.5 significant architecture changes, eg: adding pluggable triggers 2.5.03 to 2.5.04 feature releases, eg: adding support for multiple repo servers 2.5.04 to 2.5.05 feature releases, eg: windows servers now always run in unicode (unix cvsnt servers have already done this for years) 2.5.04.3236 to 2.5.04.3510 bug fixes - may be critical bug fixes Note: * major architecture changes - CVSROOT scripts may require rewriting * significant architecture changes - should be carefully planned (probably to coincide with OS upgrades) * feature releases - upgrade should always have a rollback plan * bug fixes - you should always be running the HIGHEST build Regards, Arthur Barrett