DragonFly users List (threaded) for 2005-03
Re: Version numbering for release DECISION!
: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.
I don't disagree with you, but the weight of history is a considerable
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'.