Re: [RFC] 3.1 branching

On Thu, 2008-09-25 at 22:53 +0200, Henrik Nordstrom wrote:
> On tor, 2008-09-25 at 13:32 -0600, Alex Rousskov wrote:
>
> > If we use RC label for selected/last 4-digit releases, then we will not
> > have the above problems. If a 4-digit release proves stable, we post
> > 3.1.1 (an exact copy of the last successful 4-digit release, except for
> > the version number) and mark the branch as stable.
> >
> > Is there a reason we cannot have "stable candidates" using 4-digit
> > versions?
>
> My view on "stable" after loosing the version tag:
>
> "stable" is something a release earns by proving stable. It's someting a
> release gets after being released and tested, not by a new release.
>
> Applies equal to later patch releases who also start their lives as
> "stable candidates" and then gets promoted to "stable".
>
> Also as major bugs gets discovered now known broken releases may loose
> their "stable" stamp.

The above is too extreme, IMO. We will often have no stable releases if
we remain honest and follow the above scheme to the letter:

  ...
  3.1.4 is released; no stable mark by default
  a bug is found; all previous 3.1 releases lose their stable mark
  3.1.5 is released, fixing the bug; no stable mark by default
  no bugs
  3.1.5 is marked as stable (*)
  a bug is found
  3.1.5 loses its stable mark; no 3.1 stable release available again
  3.1.6 is released; no stable mark by default
  ...

This means that except for (*) period, users will have to use Squid 3.0
or Squid 2.x (which use less draconian scheme) instead of Squid 3.1. Not
a good side-effect.

Even worse, consider a user that has a company policy to only run stable
versions. That user installs 3.1.5 and then discovers he has to
downgrade to 3.0, which lacks the feature he needs. And the serious bug
found in 3.1.5 may not even affect that user. That's just plain wrong.

I think we should mark _branches_ not individual versions. A stable
branch has certain project backing behind it. A stable version does not
mean much because bugs can always remove that flag.

Said that, if others are convinced that we should try testing and
marking each release, I am happy to try it.

> The "release candidate" process for getting to 3.1.1 is dealt with by
> the 3.1.0.X releases. The diff between the last 3.1.0.X and 3.1.1 should
> preferably just be the version number, with that 3.1.0.X being a release
> candidate for 3.1.

+1 on that.

Thank you,

Alex.
Received on Thu Sep 25 2008 - 23:12:10 MDT