Re: Stable tag will be slipped Sunday and release engineering will begin Monday

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Okay, I am proud to claim the role of the least educated and the most amateurish
:of all DFly groupies, so I will ask the painfully stupid questions :o)
:
:I've been following the long and confusing thread about what the various tags
:should be named (and why) and I am hereby declaring my total confusion.
:
:I've been following FreeBSD-CURRENT for about ten years, and yet I still don't
:understand the meaning of their tag names -- so, should I be surprised that I
:don't understand the DFly names either?
:...

    Basically it comes down to the problem of identifying what kernel and 
    world someone is running.   In FreeBSD's case they run parallel releases
    of both their 'stable' and 'current' series.  The two major series 
    (stable and current) have their own CVS branches (current is just on the
    CVS HEAD).  Each release made within the series also has its own branch.
    To make things more confusing, the -RELEASE designation only applies to
    the actual release while the -STABLE designation applies to continued 
    development on the stable branch.

    DragonFly just has one series.  i.e. no parallel development is occuring.
    When we release (starting with this upcoming release) we create a branch
    for the release.   Only bug fixes are allowed to be committed to a
    release branch... no new features. 

    As of this upcoming release, our tags are going to be named based on
    the scheme Chris Pressey came up with (the one that got a lot of positive
    responses on the lists).  We will have three tag names:

    DEVELOPMENT

	This represents the absolute bleeding edge head of the CVS tree.
	When Max commits yet another rearrangement of the Make variable
	handling module, or Joerg rearranges the sound drivers, this 
	is where it goes :-)

    PREVIEW

	This is a slip tag (not a branch) that we synchronize with the head
	of the tree from time to time (just like I did a few days ago).  It
	represents near-bleeding-edge but likely-to-not-blow-up-in-your-face
	work.

    RELEASE+subversions

	This will be a branch tag.  e.g. representing an official release.
	So, for example, the upcoming release will be called
	DragonFly 1.2.0-RELEASE (the tag name itself will be something more
	compressed).

	Commits made to a release branch will automatically bump a 
	subversion, e.g. 1.2.0, 1.2.1, ... 1.2.75.  Again, only bug fixes
	would be committed to a release branch.  So someone running a
	release who reports a bug might tell us that is is running 1.2.25,
	which gives us a darn good idea exactly what the state of his
	system is.

	Dave Sharnoff came up with a great idea to prevent commits on the
	release branch from getting out-of-synch with the subversions
	(which is only incremented once a day at most, if something had
	been committed), and that is to have a slip tag within the release 
	branch that is kept synchronized with the automated subversion
	change.  This will be what people tracking a RELEASE branch will
	be using to keep up to date, rather then tracking the branch tag
	itself.  That gets into the nitty-gritty and will be mostly 
	invisible to end-users, but I thought I'd mention it anyway.

    We do not regard releases as being production-ready.  At some point in
    the future we will put together a testing regimen and require a certain
    amount of in-the-field-time for a release branch before we start
    calling it PRODUCTION.  So, e.g.  lets say that by the time we get to
    1.2.75 there's enough feedback and testing to be able to call it 
    production, the nomenclature in the boot message would change
    from RELEASE to PRODUCTION.  Some release branches might never make it
    to that exhaulted status.

    Unlike FreeBSD subversions of old, our subversions automatically track
    commits made to a release branch, so it is expected that the subversion
    might grow to a fairly large number.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>