Re: Release early, branch later

Alex Rousskov wrote:
> 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?".

kerberos helper upgrade, LogDaemon, InternalRedirectors, my Cleanups branch.

Also very soon, NetDB re-modelling in a few weeks, minimal squid build.
A few other feature bugs I've picked up.

later:
   gzip, config parser re-modelling, ...

The list of delayed is growing already nearly as long as the list of new
in 3.1. And it's only been cooling 5 weeks waiting for eCAP.

They can all do with some boiling time in trunk and are needed right
now. The first batch are I think probably ready to go in a few weeks
ago, but not appropriate for 3.1. I was pushing the envelope with the
translations.

  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.

Yes, and nows a good a time as any to test that.

>
> 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?
>

I like the idea. But what I've seen of the underlying website support
systems can't easily handle releases in HEAD which are not labeled 3.HEAD-X.

Amos

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE9