DragonFly BSD
DragonFly kernel List (threaded) for 2011-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: DragonFly versioning plan

From: Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>
Date: Thu, 15 Sep 2011 21:49:31 -0400

Here's a summation of the thread, just cause it got long, cause some
of my original ideas have changed based on feedback, and the results
affect everyone:

- I'm proposing changing how we do releases and handle pkgsrc
releases, since they affect each other.  I'd like to move to a 1 year+
time between stable releases, and generally point people at
dragonfly-current for normal installs unless they require something as
stable as possible for production.

- This will require more MFCs back from current to stable.  It will
require less release work, and reduce the amount of work required to
sync binary pkgsrc packages.

- I would switch to building pkgsrc binaries of the latest stable
quarterly pkgsrc release on DragonFly stable only.  (They would be
usable on DragonFly-current without spurious warnings at this point,
assuming the major release number for DragonFly is the same on stable
and current)

- I would build pkgsrc-current on DragonFly-current, catching any
problems in compilation sooner.

We have several wrinkles that have prevented this, listed with
mitigating factors -

- pkg_install will refuse to install binary packages built on a newer
release of pkg_install, so it requires manual intervention to move
between quarterly releases.  I think that will be solved either in
pkgsrc (talking to Joerg S. about it) or as a feature of pkgin
(talking to iMil about it).

- The intersection between 6-month DragonFly releases and 3-month
pkgsrc quarterly releases made timing difficult.  Going to a rolling
release makes synchronization issues happen less often, or go away,
depending on how smoothly we can build.

- Less releases means less press from a version number change, but I'd
argue they aren't that effective, especially when we don't a major
feature to match the number change.  I would argue that we need to
trumpet new features, as vkernels or Hammer are far more complex than
a version bump.

Any other feedback?  Francois, you had the longer list of objections;
does this feel more like it's on the right track?

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]