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.
