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
