On Fri, 2008-09-26 at 05:45 +1200, Amos Jeffries wrote: > 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. Understood. Well, if we branch now, I think you will not have cycles to work on the above for at least a month, because of the back/forward porting overhead, _especially_ if the trunk becomes open again. I wonder if it would be more _efficient_ to make 3.1.0.1 snapshot from the branch in early October, followed by one or two more snapshots, and then a branching point sometime in November (depending on early 3.1.0.x feedback)? For example, this would allow us to finish the "source layout" project _before_ we branch, saving tons of time down the road. No matter how smart bzr is, I am sure that moving, splitting, and renaming 90% of the source files is going to complicate merging so it is better to do that before the branching point... > > 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. Do we need those systems for a few temporary 3.1.0.x snapshots? Can we build and post them on the web site by hand? Thank you, Alex.