Re: [RFC] 3.1 branching

On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote:
> >
> > So how do we tell users to try something between 3.1.0 and 3.1.1? Refer
> > to some specific daily snapshot? Kinkie+ scheme would use numbered beta
> > releases: 3.1.0.1, 3.1.0.2, etc.
> >
> > I think numbered releases are better than daily snapshots for asking
> > users to try something: "Argh! Somebody committed a bug 5 minutes before
> > the snapshot we thought we would recommend to the user. Let's wait
> > another day and hope that it does not happen again. People! Please do
> > not commit anything because we need a clean daily snapshot!".
>
> Thats all in trunk. We are talking numbering systems for the branches.

I am talking about the freshly branched branch, not the trunk. Snapshots
are fine for the trunk.

> To which the only commiter should be the branch maintainer.

This is a different issue, but I do not think that limiting access is a
good idea until the branch becomes stable. When 3.1 is branched (which
you want to happen soon), there will be a lot of cleanup work still
going on. I see no reason to make that work go through a maintainer. If
that is indeed a requirement, we should not branch 3.1 for now.

> We can make a
> new clean snapshot at any point if its really warranted, even to the point
> of calling it a 3.1.0.1 'release' 3 times in one day.

Yes, in Kinkie+ scheme, we can. You scheme does not mention 4-digit
releases, even for the branch in a development stage.

> > The extra "development release" layer in Kinkie+ scheme is only used for
> > 3.1.0, never for 3.1.6 or other non-zero releases.
>
> This is a contradiction of your earlier how do we tell users to try
> something between 3.1.0 and 3.1.1?"

I do not see a contradiction. 3.1.0.x releases are expected. 3.1.1.x
releases are not.

> The 'please try X' request is done as often after 3.1.1 as before.

If 3.1.1 is stable, than the number of such requests would be low enough
to be satisfied with patches and such. The next "official" trial point
would be 3.1.2.

> We come back to the problem of until squid is 100% major bug free for all
> users (now and in future) it never actually qualifies for that 3.1.1
> rating.

Correct. That is why we want 4-digit releases to test how stable the
branched code is. The more stable it gets, the more users will try them,
and the more confident we will become that it is indeed stable. At some
point, we will release 3.1.1 and mark the branch as stable.

> Under my scheme, we would not grant such development test points a full
> version number, they can get a rc1, rc2, etc (or as at present a
> '20080912') if needed.

That was your original proposal, yes. So Kinkie suggests 4-digit
development versions. You now re-suggest 3-digit plus rcW for the same
purpose. IMO, Kinkie's scheme is better because not all those snapshots
are actually "release candidates". Again, it is better to leave complex
metadata outside of the release version or tag.

> >> People seem happy with the release approach and timelines, just not the
> >> current bad naming scheme which implies releases are guaranteed STABLE
> >> when in fact only a bug fix improvement.
> >
> > Well, there are several problems with the current scheme, but I think we
> > should preserve the notion of a "stable" state of the branch. It is not
> > a guarantee, but it allows users to select the right branch/version to
> > deploy. In Kinkie+ scheme and in your scheme, the branch is considered
> > stable when 3.1.1 is released. Before that, there are big known bugs.
> > After that, there should not be any and those that appear should get
> > higher fixing priority.
> >
> > The only significant difference I see is that you want folks to use
> > daily snapshots during "development" stage of the branch and Kinkie
> > wants sub-numbered releases.
>
> Yes, pretty much.
> If you look at the changeset pages for each 3.0 release so far, there are
> fixes for some very major bugs in there as far as 3.0.STABLE7.

Yes, and that is OK. Stability does not guarantee lack of bugs.

> If we had run a whole cycle of 3.0.0.N (aka 4 years of testing PRE1 ->
> RC2), we would have still probably have released 3.0.1 (aka 3.0.STABLE1)
> with those bugs in. Or maybe gone straight from 3.0.0.16 to 3.1.0.1 this
> month

Again, there will be no 3.1.0.1. Once the branch is marked as stable, we
stop doing intermediate development releases. That is my understanding
of what Kinkie and Henrik want, anyway.

> I don't realistically expect 3.1 to be perfect either.
>
> I'd rather have fixed point releases (3.0.1) based on some known workable
> code, and a pile of sequentially tagged bundles of 'maybe dodgy code' on
> top for new un-tested bug fixes.

Sure, the only need that we need to address for those bundles during
non-stable branch development is that the bundle is not controlled by
time, but by a human decision to tag/release it.

Alex.
Received on Thu Sep 25 2008 - 14:11:30 MDT