DragonFly versioning plan

[Matthew Dillon]

    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