[cvsnt] Re: Thoughts on version numbering

Bruce Hill bhill at euphonix.com
Thu Mar 20 22:56:54 GMT 2003


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 like John's suggestion from below.
i.e.
<major release>.<minor release>.<patchlevel>
where even <minor release> numbers designate stable releases
and odd <minor release> numbers are used for new development.
This allows for patches to stable releases while new development
proceeds using development patch levels.

2.0.0		- Stable release
2.1.0		- First beta for new feature
2.1.1		- Next beta for new feature
2.0.1		- Bug fix for 2.0.0
2.1.2		- Another stab at the new feature
2.2.0		- Next stable release with latest features

The only drawback I see to this scheme, is that development
releases may not get tested as much.   The benefit is that
users who currently avoid upgrading for fear of bugs would
have more confidence upgrading to the latest stable release,
so we would tend to see fewer problems related to old versions.

I'd suggest posting a request for additional testing when
a development release is nearly ready to become a stable release,
and wait for a month with no major or critical bugs before making
it the next stable release.
 
- Bruce Hill

Tony Hoyle wrote:
> 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.
> 

You can also consider the <major release>.<minor release>.<patchlevel> and
odd=devel, even=release model that Perl follows now.  By this scheme, the next 
stable release should be 2.0 and the devel stream begins immediately at 2.1 
(where patchlevel releases are incremented seperately).  When you get to the 
point where the devel version is stable enough to release, it becomes 2.2 and 
2.3 immediately starts as the devel stream.

And I would _not_ suggest doing anything except leapfrogging over the existing 
CVS version scheme.

John


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook