Version numbering for release DECISION!

[Bill Hacker]

Matthew Dillon wrote:

: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.
Exactly.  Spike it where it lies.

Everything has had *some* testing.
Very little has had *enough* testing.
    Other projects use DEVELOPMENT so we could use that instead of CURRENT,
    and it is certainly more informative.
Likewise. CURRENT just carries too much 'weight of history' ...
historically misleading.  Not to mention the way nearly
all of us use the term in communications...
'well, first you should upgrade to a current {version | release]....'

When we may mean ..
'the currently-accepted most-universally trouble-free
(whatever that is titled as)'
    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).
'Old Cynical Fart' takes that a step further - with all due respect to
one Hell of a lot of hard work and good ideas invested to date,
. ..'PRODUCTION' is still a bit of a stretch.
DragonFly is not yet 'turnkey'.  Too few installations testing
with common and uncommon hardware and applications,
vs, for example FBSD 4.X
I would go so far as to say that the advances of the past 3 months
may have made the product *temporarily* less stable (in the user sense)
than earlier releases.
Can't make a fresh omelette without breaking eggs, and each day
brings greater penetration into and replacement of legacy code
'eggs'.
    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'.
Required.  Might not happen as fast as we woudl like,
but anything less and DFLY risks loss of credibility.
					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>
So June 04 was 'Release 1.0' perhaps June '05 can be 'PRODUCTION 1.1'

The chances of more folks running it on more platforms and with
more apps should be greatest if they better understand what to
try, what to expect of it, and under what circumstances.
Developers are not the problem - most have to track stuff
by tarball file dates anyway... too many versions on hand
to do otherwise ;-)
Bill