Release early, branch later

On Thu, 2008-09-25 at 22:41 +1200, Amos Jeffries wrote:

> Like they are confusing trunk stabilization with branch stabilization.

FWIW, my stabilization expectations are based on your intent to branch
3.1 soon. I know that it will take at a few releases to get 3.1 to a
stable point from where the trunk is now. Thus, I was arguing for an
ability to release a few development versions after we branch, with no
indication that those versions are "pre-stable" or "stable candidates".

If you want to reduce back/forward-porting between trunk and 3.1 branch
then let's not branch soon! Let's bring the code closer to stable first.

When I was doodling a "better release procedure" a month or so ago, I
actually thought that branching "late" can force folks to work on code
stability (rather than rush to develop for the now unfrozen trunk,
abandoning a half-baked branch).

While I tried to support your deadlines, my first question on this
thread was "Are there any big trunk changes that are waiting for v3.1
branching?". You have not answered that, but let's assume there aren't
any. If that is the case, given the number of folks actively working on
Squid right now, and what they are actually doing, there appears to be
no rush to branch, especially if your goal is to minimize
back/forward-porting overheads (which is a very reasonable goal given
our resources!).

If we do decide to branch soon, we definitely need a mechanism to make
more than one development release. If we decide to make the code stable
first, then the pressure will be less, but we still need that mechanism.

This would probably go against standard branching principles, but we
could even make those 3.1 development releases _before_ the code is
branched. The users do not care about branches and it will save us a lot
of back/forward-porting time if we release first and branch later.

What do you think?

Thank you,

Alex.
Received on Thu Sep 25 2008 - 15:10:30 MDT