Re: Release early, branch later

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.
Received on Thu Sep 25 2008 - 18:40:15 MDT