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
