DragonFly versioning plan

[Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>]

I've been thinking for some time about our releases, and how we plan
them out.  I've got a proposal here which fixes a number of issues for
us, but I want to see what other people think.  It's a bunch of text;
if you are really impatient, skip the justifications and go right to
the ideas at the end.

Here's the problems I'm trying to fix:

 - pkgsrc updates twice as fast as our release schedule, and
subsequent quarterly releases of pkgsrc will not work with the
previous release's tools, breaking binary package installs.
(pkg_install checks its version and will refuse to install packages
built with a newer version of pkg_install; a change from the last year
or so.)  It also means there can be multiple binary package sets for 1
DragonFly release.
- I've been building pkgsrc quarterly releases for binaries, which is
fine, but it would also be nice to have pkgsrc-current reports to show
how much breakage there would be.
- Bulk builds of pkgsrc are automated, but there's always gotchas -
the occasional package that won't ever finish building, machine
reboots for unrelated reasons, etc., and adding more machines into the
mix would add to the load.
- When DragonFly started, we used cvs, and had RELEASE and PREVIEW,
and of course HEAD.  This meant there was RELEASE for people who
wanted stability, PREVIEW for people who wanted new features but
couldn't handle too much breakage, and HEAD for people who liked
living dangerously with the newest code.  Nowadays, this behavior has
evolved.  We've switched to git, and people either run a relatively
recent release (like me) or just run the git equivalent of HEAD.
('master', I suppose.)  Breakage for HEAD has been rare and quickly
fixed.
- Conversations in the past about updating DragonFly usually break
down into 3 groups: people who update all the time; people who go from
release to release, and people who never update.  We often end up
telling people to run the most recent daily build image of DragonFly
for driver support, or to catch some recent fix.  I'd like to not even
have to go through the "install - have problem - install again, newer
version" cycle, given that we already have people running DragonFly
current.

Here's the proposal to fix these problems:

- We release a "long term version" of DragonFly, at some arbitrary
release number, with an arbitrary long term window - 3 years, maybe?
When we MFC, it's to that version.  People who need a server that
'just works' can use it.  I can build a set of pkgsrc binary packages
for it, and leave them alone after that quarterly release is done.  It
does mean that updates for that software won't happen after a certain
point as binaries, but it avoids the scenario where a brand new
install can't install any binary, or pkg_install refuses to work, or
whatever.  I don't want DragonFly to be broken "out of the box", and
the whole idea is that stability is paramount here.

- We point people at DragonFly-current for everything else.  That way,
everyone's generally on the same version unless they explicitly opted
for something else, and we don't have to say "well, install a
completely new version", and we have more people trying new features.

- DragonFly-current being the more common target, I can go to
pkgsrc-current for the binary package builds on it too.  This does
have some risk, as a major library upgrade of, say, libjpeg or
gettext, can have a few days of repercussions, but we'll know about
the build problems sooner.  People for whom this is a problem can jump
back to a quarterly release.

- This reason isn't as practical, but when I write about some new
feature on the Digest, I like the thought of people updating and using
it right away, rather than waiting some number of months for the next
release.

My thoughts behind this:

I've been wanting to suggest changes to the release process for a
while, but I wasn't coming up with a concrete set of ideas.  Then, I
was reading this description of how GitHub handles development, and it
strikes me that we're following many of these practices in an informal
way already:

http://scottchacon.com/2011/08/31/github-flow.html

So, this proposal is a way to bring our established-by-practice
development style into our actual release cycle.

You get a gold star if you read all the way to the end of this giant
text block.  Thoughts?  I want to get this discussion public, rather
than just informal on IRC.  I'd especially like feedback on how long
"long term" should be.