Re: DragonFly versioning plan

[Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>]

What I'm thinking is that we have a rolling release, as other systems
have done.  If you run current, it's marked with the day of build,
perhaps, but it's a new build of the installer every day.  We have
people doing that now.

If we move to a year+ for the stable release, there's only one thing
to MFC to.  We wouldn't have as frequent press for version releases,
but I don't think that's a very effective attention-getter; I'd rather
trumpet new features.  We also don't have a lot of differentiation
between minor versions right now, either, which also makes it less
effective as an attention-getter.

Scheduling the next release date way ahead of time makes it a bit
easier to plan.

I'm OK with still building package sets for two different releases.
Packages built on the stable release will no longer put out a cosmetic
complaint about version number when installed on a release with the
same major number, so they can go on the -current build too, as long
as we don't have an ABI change.  (thanks to ... David Brownlee?  I
forget which pkgsrc developer fixed this up, but it's appreciated.)
We could even default the binary install to the pkgsrc quarterly
release on -current too, if that's too bleeding-edge otherwise.  If
the pkg_install issue gets changed/fixed, rolling builds of
pkgsrc-quarterly would be possible too, which would really make things
easier - 1 full rebuild per DragonFly release, instead of 4-6 per
year, depending on when pkgsrc and DragonFly releases happen.

Instead of building quarterly packages for stable and current
DragonFly as I do now, I'd build quarterly packages for stable and
pkgsrc-current for -current, which is more valuable.  (As Sascha has
pointed out to me, quite correctly, several times.)

So our work level would be less releases, but more attention to MFC.
We can't get around more MFC because we just plain don't do it much
now.  Bulk building load would be close to the same, but it would
hopefully find problems sooner because pkgsrc-current would be built
and reported on, more often.  I suppose I'd feel much more effective,
which goes a long way towards reducing apparent work load.


On Tue, Sep 13, 2011 at 12:37 AM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>    I'm trying to figure out the exact logistics of how this would work and,
>    in particular, how it would reduce our development and build chores.
>
>    In all cases my presumption is that we release a -current every 6
>    months just as we do now (otherwise things won't stay fresh and we
>    won't have enough press), but it wouldn't be as big a deal as it
>    is now... just another tag on -current and NOT a branch.  Then once a
>    year (or less often) we branch a major stable release ?  We have to
>    branch a new stable release on some schedule.
>
>    On choosing which tag to branch for the once-a-year stable release we
>    could use whichever tag in the last year seemed the most stable...
>    I guess, branch, and reapply any MFCs that hadn't made it from that
>    tag.  I'm not sure this would be less work.
>
>    Perhaps to make it more useful we would do a -current release 4 times a
>    year so we'd have 4 tags to choose from when rolling the next stable
>    release.  If the -current releases are not 'a big deal' (i.e. just a tag,
>    not a branch), and since all pkgsrc builds would be using the stable
>    release, then the -current releases really would not be that big a deal
>    and we could do more of them.  We wouldn't have to rebuild packages for
>    the -current releases per-say.
>
>    --
>
>    If that's the logistics then I see two problems:
>
>    First, we would still be building package sets for different releases
>    with your plan.  The quarterlies for stable, the pkgsrc-current for
>    current.  I think this creates a lot of the problems we already have
>    currently, yah?  Would building ALL the pkgsrc sets on stable
>    (quarterlies AND pkgsrc-current) be a better solution?  Someone
>    running stable is still going to want to be able to move between package
>    sets and possibly even use pkgsrc-current.  And similarly someone running
>    -current also wants the same flexibility.
>
>    If we don't build pkgsrc-current for the stable release then we have
>    no easy way of ensuring compatibility because most people will be running
>    -current and it would be hard for those running -stable to get action on
>    reported problems.
>
>    On the otherhand, if we build the pkgsrc quarterlies AND pkgsrc-current
>    ONLY on the stable release (and use them for -current and -stable), then
>    all the people running it on the current release can report when things
>    break due to compatibility issues between stable and current, and we
>    can more easily take action to fix the incompatibility in current.
>
>    This would be an easier development process I think.  Logistically,
>    less work for us when all pkgsrc binary building occurs on the stable
>    release.
>
>
>    Second problem is that we still have to update the stable release every
>    once in a while, with the same issues that we have when we do our current
>    stable release.  So if we do a stable release once a year we haven't
>    really solved anything vs doing a stable release once every 6 months.
>
>    A mitigating factor for #2 is that the better package compatibility
>    between current and stable (even with a 1 year difference) would mean
>    that the issues related to the OS upgrade shouldn't be as bad as they
>    have in the past.
>
>    Customers would still be able to choose which pkgsrc release to use...
>    a particular quarterly or pkgsrc-current.
>
>
>    What do you think?
>
>                                                -Matt
>
>