Version numbering for release DECISION!

[Matthew Dillon]

:I agree 100% that the names should indicate the _purpose_ of the thing
:rather than its state or circumstances, simply because most people will
:be more interested in its purpose than in other factors.
:
:So PRODUCTION is a better name than STABLE, DEVELOPMENT is a better name
:than UNTESTED or CURRENT, and PREVIEW is a better name than WORKING.
:
:-Chris

    I don't disagree with you, but the weight of history is a considerable
    factor here.

    I like PREVIEW instead of WORKING.  It implies a not-as-well-tested
    build but one which is also not necessarily bleeding-edge.

    Other projects use DEVELOPMENT so we could use that instead of CURRENT,
    and it is certainly more informative.

    I do not like using PRODUCTION or STABLE, at least not in a release
    branch that has gone through only normal release engineering.  I would
    prefer we just call releases and sub-releases RELEASE and not
    differentiate between the original release and commits made to the
    release branch (other then bumping the sub-version).

    We could institute a more rigorous testing procedure in order to change
    the RELEASE designation into a PRODUCTION designation.  For example,
    lets say we have a release branch, 1.2.0, and after a few months of
    commits the subversion is up to 1.2.23, and we decide that THAT branch
    is now production ready (remember the old addage, a .0 is NOT a production
    release, and a .1 isn't necessarily a production release either, and
    maybe not even .2, or .3 :-)).  When the decision is made, the RELEASE
    designation on that branch would become a PRODUCTION designation, meaning
    'ultra reliable, uber stable, regression tested, lots of field testing,
    etc etc etc'.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>