This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Release 0.26: branching
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, Matthias Klose <doko at ubuntu dot com>, Binutils <binutils at sourceware dot org>
- Date: Tue, 17 Nov 2015 15:51:42 +0000
- Subject: Re: Release 0.26: branching
- Authentication-results: sourceware.org; auth=none
- References: <CE8D8950-0957-43A2-AD8B-448FB84C0B65 at adacore dot com> <5645B354 dot 8040909 at ubuntu dot com> <20151114012904 dot GQ5154 at vapier dot lan> <96F766D7-48E6-4044-94FD-907DF9352303 at adacore dot com> <20151116235747 dot GG31395 at vapier dot lan> <564B3326 dot 8040801 at foss dot arm dot com> <alpine dot DEB dot 2 dot 10 dot 1511171531390 dot 14808 at digraph dot polyomino dot org dot uk>
On 17/11/15 15:34, Joseph Myers wrote:
> On Tue, 17 Nov 2015, Richard Earnshaw wrote:
>
>> My suggestion would be to run a lighter weight version of the GCC
>> development process (which I think works very well overall) with perhaps
>> a 5-month development window followed by a one month stabilization
>> window. At the end of that month the release branch is cut and a
>> release made from it once the code is suitably validated. Backporting
>
> This sounds like the glibc release process (except that glibc releases are
> made from master and the branch then made with the release point as the
> branch point).
>
Possibly; glibc doesn't really do much in the way of maintenance
(re)releases though.
R.