Re: DragonFly versioning plan

[Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>]

Samuel, To answer your last two items, pkgsrc does not now complain
about differences in minor version number for the operating system,
for DragonFly.  It used to, but that check was removed.  Also, I have
been talking with iMil about pkgin, and he suggested having pkgin
auto-add pkg_install as a dependency if there was a newer binary
available, so that may well fix it.

People like the 6-month schedule, it seems.  I would like to have some
sort of long-term release of DragonFly, though, for scenarios where an
administrator can't rebuild every 6 months.  I'm not sure how to do
that along with a 6-month release schedule that doesn't involve a lot
more overhead work for us.  We can certainly implement the rest of
these idea without it, and let that problem just lay there for now.

On Fri, Sep 16, 2011 at 4:09 AM, Samuel J. Greear <sjg@evilcode.net> wrote:
> "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
>