Re: DragonFly versioning plan
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
討論串 (同標題文章)
完整討論串 (本文為第 9 之 16 篇)：