Re: DragonFly versioning plan
What I'm thinking is that we have a rolling release, as other systems
have done. 啱f you run current, it's marked with the day of build,
perhaps, but it's a new build of the installer every day. 咗e have
people doing that now.
If we move to a year+ for the stable release, there's only one thing
to MFC to. 咗e 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. 咗e 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? 啱
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. 啱f
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. 脷ulk 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. 啱 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:
> ꀠ啱'm trying to figure out the exact logistics of how this would work and,
> ꀠ湶n particular, how it would reduce our development and build chores.
>
> ꀠ啱n all cases my presumption is that we release a -current every 6
> ꀠ滟onths just as we do now (otherwise things won't stay fresh and we
> ꀠ烀on't have enough press), but it wouldn't be as big a deal as it
> ꀠ湶s now... just another tag on -current and NOT a branch. 糍hen once a
> ꀠ∂ear (or less often) we branch a major stable release ? 咗e have to
> ꀠ毪ranch a new stable release on some schedule.
>
> ꀠ嘢n choosing which tag to branch for the once-a-year stable release we
> ꀠ氲ould use whichever tag in the last year seemed the most stable...
> ꀠ啱 guess, branch, and reapply any MFCs that hadn't made it from that
> ꀠ濳ag. 啱'm not sure this would be less work.
>
> ꀠ嘭erhaps to make it more useful we would do a -current release 4 times a
> ꀠ∂ear so we'd have 4 tags to choose from when rolling the next stable
> ꀠ澑elease. 啱f the -current releases are not 'a big deal' (i.e. just a tag,
> ꀠ滢ot a branch), and since all pkgsrc builds would be using the stable
> ꀠ澑elease, then the -current releases really would not be that big a deal
> ꀠ乸nd we could do more of them. 咗e wouldn't have to rebuild packages for
> ꀠ濳he -current releases per-say.
>
> ꀠꀭ-
>
> ꀠ啱f that's the logistics then I see two problems:
>
> ꀠ啫irst, we would still be building package sets for different releases
> ꀠ烀ith your plan. 糍he quarterlies for stable, the pkgsrc-current for
> ꀠ氲urrent. 啱 think this creates a lot of the problems we already have
> ꀠ氲urrently, yah? 咗ould building ALL the pkgsrc sets on stable
> ꀠꀨquarterlies AND pkgsrc-current) be a better solution? 嚒omeone
> ꀠ澑unning stable is still going to want to be able to move between package
> ꀠ澵ets and possibly even use pkgsrc-current. 孭nd similarly someone running
> ꀠꀭcurrent also wants the same flexibility.
>
> ꀠ啱f we don't build pkgsrc-current for the stable release then we have
> ꀠ滢o 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
> ꀠ澑eported problems.
>
> ꀠ嘢n the otherhand, if we build the pkgsrc quarterlies AND pkgsrc-current
> ꀠ嘢NLY on the stable release (and use them for -current and -stable), then
> ꀠ乸ll the people running it on the current release can report when things
> ꀠ毪reak due to compatibility issues between stable and current, and we
> ꀠ氲an more easily take action to fix the incompatibility in current.
>
> ꀠ糍his would be an easier development process I think. 㗒ogistically,
> ꀠ溻ess work for us when all pkgsrc binary building occurs on the stable
> ꀠ澑elease.
>
>
> ꀠ嚒econd problem is that we still have to update the stable release every
> ꀠ漑nce in a while, with the same issues that we have when we do our current
> ꀠ澵table release. 嚒o if we do a stable release once a year we haven't
> ꀠ澑eally solved anything vs doing a stable release once every 6 months.
>
> ꀠ孭 mitigating factor for #2 is that the better package compatibility
> ꀠ毪etween current and stable (even with a 1 year difference) would mean
> ꀠ濳hat the issues related to the OS upgrade shouldn't be as bad as they
> ꀠ温ave in the past.
>
> ꀠustomers would still be able to choose which pkgsrc release to use...
> ꀠ乸 particular quarterly or pkgsrc-current.
>
>
> ꀠ咗hat do you think?
>
> ꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀠꀭMatt
>
>
討論串 (同標題文章)
完整討論串 (本文為第 12 之 16 篇)：