2.12.x branch future?

Daniel Jacobowitz drow@mvista.com
Sat Mar 16 17:45:00 GMT 2002


On Mon, Mar 11, 2002 at 03:05:37PM -0800, cgd@broadcom.com wrote:
> At Sat, 9 Mar 2002 21:28:33 +0000 (UTC), "Daniel Jacobowitz" wrote:
> > > Is there going to be a 2.12.1?  ("hope so" 8-)
> > 
> > I don't know.  I would rather not; I would rather a 2.13 whenever
> > someone feels the need for a 2.12.
> 
> I can understand that.  8-)

Let me elaborate on my reasoning here, even though I intend to reopen
the branch anyway.

Suppose that some amount of time has passed, or some problem been
discovered, that we decide another release is meritted.  If we decide
to release from the 2.12 branch, we will still need to retest it on all
interesting platforms, and we will still need to spend some time
importing fixes from the trunk.  If we decide to release from the
trunk, we need to do the same testing, probably some amount more
fixing, but less pulling patches - and pulling patches once the two
have diverged can be fairly risky.

In a project like GCC, where two months are necessary to restabilize,
the merit is obvious.  In a project like the binutils, where we are
almost always stable except for a week or two after a large patch, it's
not so clear.

> It's much easier to begin accumulating "important" fixes immediately
> if there's _any_ chance of a 2.12.1 release.
> 
> (It also means that if people _do_ want to try to follow the head of
> the release branch, to get the latest greatest 'stable' fixes, they
> could do that... in fact, _I'd_ probably do that for some purposes,
> but to my mind that's secondary.)

Another good reason.

The branch is open.  I ask that any non-trivial patches (where
something like the lbasename () stuff is trivial, but something like
Alan's useful incompatible word size error is not trivial) sit on the
trunk for at least a day or two in case someone notices a problem.

Also, just as a technical matter, I would prefer that ChangeLog entries
be dated with the commit-to-branch date and in that order, rather than
trying to match the trunk ChangeLog.  Rationale: It serves as a better
log of changes that way, even if sorting out differences between trunk
and branch becomes a little harder.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer



More information about the Binutils mailing list