Patch policy for branches

Patch policy for branches

[Mark Mitchell]

In the past, we've had a confusing situation for users, in which
"upgrading" from one branch to another could result in known
regressions.  In particular, consider our current situation:

* GCC 4.0.2 is the latest release on the 4.0 branch.

* GCC 4.1 will be released soon.

* GCC 4.0.3 will be released at some time in the future.

Suppose that after GCC 4.1, we fix a bug, applying the fix to both the
4.0 and 4.1 branches.  Then, we release GCC 4.0.3, before GCC 4.1.1.
The result is then that a user who uses GCC 4.0.3, and upgrades to GCC
4.1.0, sees a regression for the bug in question.  That seems confusing.

We didn't use to have this problem because we use to have only one
active release branch.  However, for a while now, we've had at least
two, and sometimes three, active release branches, responding to a
demand from some users for longer lifetimes for our release branches.
So, now we have the problem outlined above.

The best solution I can think of is to synchronize releases across
active branches so that GCC 4.0.3 and GCC 4.1.0 would be released
simultaneously.  The other option would be to postpone applying patches
on the 4.0 branch until after a 4.1 release has been made with that
patch applied, but that seems administratively difficult.

As RM, I am willing to manage the releases of two active branches
together.  I've already announced that 4.0.3 would be released shortly
after 4.1.0, so I think we can achieve near-simultaneous release of
4.0.3 with 4.1.0, and the 3.4.x branch is official dead at this point.
However, assuming that Gaby plans to take over the 4.0.x branch (does
he?), then I would need Gaby's buy-in to ensure simultaneity going forward.

I'd also be interested in other feedback.  The obvious negative with the
proposed plan is that it means that more scarce resources (RM, testers,
etc.) are required over a shorter period, rather than being spread
across time.

Thoughts?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Patch policy for branches

[Matthias Klose]

Mark Mitchell writes:
> and the 3.4.x branch is official dead at this point.

No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html

  Matthias

Re: Patch policy for branches

[Mark Mitchell]

Matthias Klose wrote:
> Mark Mitchell writes:
>> and the 3.4.x branch is official dead at this point.
> 
> No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html

My mistake; thanks for the pointer.

However, that doesn't change the general thrust of my mail;  the only
issue is how soon we must begin to coordinate.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: Patch policy for branches

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

Mark Mitchell <mark@codesourcery.com> writes:

> In the past, we've had a confusing situation for users, in which
> "upgrading" from one branch to another could result in known
> regressions.  In particular, consider our current situation:
>
> * GCC 4.0.2 is the latest release on the 4.0 branch.
>
> * GCC 4.1 will be released soon.
>
> * GCC 4.0.3 will be released at some time in the future.
>
> Suppose that after GCC 4.1, we fix a bug, applying the fix to both the
> 4.0 and 4.1 branches.  Then, we release GCC 4.0.3, before GCC 4.1.1.
> The result is then that a user who uses GCC 4.0.3, and upgrades to GCC
> 4.1.0, sees a regression for the bug in question.  That seems confusing.

Did you really hear that many complaints that it's worth to take care
of this?  

If we have a minor release of 4.1 every two month that means a time of
less than two month where a user first updates to 4.0.3 and then to
4.1.0. I doubt that users update in that way so often that we have to
take care of that.

On the other hand, I know of users that have several branches
installed to test both old and new compilers and those might get hit
by this,

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Patch policy for branches

[Gabriel Dos Reis]

On Sun, 19 Feb 2006, Mark Mitchell wrote:

| Matthias Klose wrote:
| > Mark Mitchell writes:
| >> and the 3.4.x branch is official dead at this point.
| >
| > No, see http://gcc.gnu.org/ml/gcc/2005-12/msg00189.html
|
| My mistake; thanks for the pointer.
|
| However, that doesn't change the general thrust of my mail;  the only
| issue is how soon we must begin to coordinate.

I agree.  GCC-3.4.x is dead after 3.4.6, which is end of this month.
So Mark's general point remains.

-- Gaby

Re: Patch policy for branches

[Gabriel Dos Reis]

On Sun, 19 Feb 2006, Mark Mitchell wrote:

| In the past, we've had a confusing situation for users, in which
| "upgrading" from one branch to another could result in known
| regressions.  In particular, consider our current situation:
|
| * GCC 4.0.2 is the latest release on the 4.0 branch.
|
| * GCC 4.1 will be released soon.
|
| * GCC 4.0.3 will be released at some time in the future.
|
| Suppose that after GCC 4.1, we fix a bug, applying the fix to both the
| 4.0 and 4.1 branches.  Then, we release GCC 4.0.3, before GCC 4.1.1.
| The result is then that a user who uses GCC 4.0.3, and upgrades to GCC
| 4.1.0, sees a regression for the bug in question.  That seems confusing.
|
| We didn't use to have this problem because we use to have only one
| active release branch.  However, for a while now, we've had at least
| two, and sometimes three, active release branches, responding to a
| demand from some users for longer lifetimes for our release branches.
| So, now we have the problem outlined above.
|
| The best solution I can think of is to synchronize releases across
| active branches so that GCC 4.0.3 and GCC 4.1.0 would be released
| simultaneously.  The other option would be to postpone applying patches
| on the 4.0 branch until after a 4.1 release has been made with that
| patch applied, but that seems administratively difficult.

I agree with the last observation.

| As RM, I am willing to manage the releases of two active branches
| together.  I've already announced that 4.0.3 would be released shortly
| after 4.1.0, so I think we can achieve near-simultaneous release of
| 4.0.3 with 4.1.0, and the 3.4.x branch is official dead at this point.
| However, assuming that Gaby plans to take over the 4.0.x branch (does
| he?), then I would need Gaby's buy-in to ensure simultaneity going forward.

I agree with your general plan.

I planned to release GCC-3.4.6 at the end of this month.  So, I think
we can proceed with for your outlined plan for GCC-4.0.x and upward.

-- Gaby

re: Patch policy for branches

[Dan Kegel]

Some projects have a time-based release strategy
(e.g. "we release once every six months").

Would it make sense for gcc to do that
for all maintenance releases?  e.g.
leave the current process the same for .0
versions, which users are scared of anyway,
but coordinate all other releases
to occur once per quarter?


--
Wine for Windows ISVs: http://kegel.com/wine/isv