Re: DragonFly versioning plan

["Samuel J. Greear" <sjg@xxxxxxxxxxxx>]

"Maybe we come up with an alternative solution that doesn't require a
change in the release schedule."

+1


If pkgsrc is the problem then directly addressing that problem seems
more prudent, we can then later change how releases are done if we
still think the reasons for doing that are valid.

As I type this I am also installing a new desktop, for whatever reason
I am installing the 2.10 release instead of the latest snapshot -- but
I suspect given the option most users will definitely gravitate toward
a "release" over a "snapshot". I have had to fight several issues to
even get DF installed that I believe are fixed in master (ahci and
interrupt routing issues). So given my impressions from today as a
sole data point, a six month release schedule is far too slow. But..
3 months is too much work, and a year is just way, way too long. The
current release schedule is an excellent compromise and forces us to
firm up the tree a bit twice a year and document the changes we have
made. Really, we do 6 month releases (vs rolling or 3 or 12) for good
reasons, and there is no silver bullet. Current snapshot builds are an
effective rolling release and most developers and some power users go
this route. But I don't see why we can't implement your plan leaving
the release cycle the way it is now.

Releases, quarterlies, yearly, master, stable, etc...  This is all in
large part semantics, I think. Why can't we just pick a release, call
it 2.10 -- and designate it internally as a "package build release",
and then build quarterlies on it until such time as we (and by we I
mean you, Justin) declare a new "package build release" in 12-24
months time? (Nobody has mentioned issues we have to fix in DragonFly
that are exposed by non-building/broken pkgsrc builds, these will have
to be MFC'd to whatever release the stable/quarterly builds are
happening on in any case, but they are few and far between).

If we are ensuring forward binary compatibility, as we would
absolutely have to do in either scenario (mine or yours), there is no
reason we should not just change the package tools to install any
package without complaint about the OS version as long as the version
is greater than or equal to the version it was built on. .. at least
for the same major version (currently "2"). (Maybe it will already do
this just fine).

Why can't we just add pkgtools as a pkgsrc port (if it isn't already)
and then force a dependency on it into all the packages we build?
Wouldn't that pretty much solve the tools problem? In that case pkgin
would just paper over any issues for you by sucking in and installing
the new tools.


Sam