DragonFly versioning plan

[Francois Tigeot]

On Sat, Sep 10, 2011 at 09:28:38PM -0400, Justin Sherrill wrote:
> 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.)

If this is a problem, it should be more acute for NetBSD, which has a longer
release schedule. I'm curious about what solution they have figured out.

It is also perfectly possible to build pkgsrc binaries with the tools of
the previous quaterly release. pkg_install from 2011Q1 can be used to create
2011Q2 packages, thereby removing the binary compatibility problem entirely.

> - 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.

3 years is a long time; I'm not sure the DragonFly project has the resources
to maintain a release for so long.
Besides, long term releases (Ubuntu and Debian come to mind) have a tendency
to rapidly become obsolete on the driver side and not work with newer
hardware.

> 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.

What about security updates ? At one time, we'll have 3-years old packages
full of security holes and the long-term release will also be broken out of
the box, albeit in a different way...

> - 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.

Or not; without the right mix of stability _and_ up-to-date features, many
users could just abandon DragonFly entirely.
I, for one would not install an experimental version on production servers,
and I would not buy refurbished hardware to run a 3-years old one either.

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

Development != release
An operating system is different from a website; you can't force people to
upgrade according to your schedule.

I don't see any obvious benefit to what you're proposing either. The current
release cycle (2 releases per year) is not broken and is IMHO a good
compromise.

Pkgsrc binary compatibility is not a real problem (what's wrong with removing
the previous binary packages before installing new ones ?) and can be fixed by
building packages in a slightly different way or installing from source.

Why fix DragonFly ?

-- 
Francois Tigeot