Handling of the actively-maintained branches (master, stable-2.0)

Handling of the actively-maintained branches (master, stable-2.0)

[Andreas Rottmann]

Hi!

I just noticed that currently, master is mostly not being commited to,
and fixes accumulate in stable-2.0.  The exception to this being the
recent change that fixes popen.test (thanks for nailing that one,
Mark!), which has been applied to both branches.  

I wonder how this generally should be handled -- I think the most
appropriate way would be to commit any changes that can go into the
stable release into stable-2.0 (only), and then, at "convenient times"
(perhaps always before committing new, not-for-stable stuff to master)
merge stable-2.0 into master.  It probably doesn't matter, as git seems
to handle duplicate changes quite well (just tried, except for a
conflict in GUILE-VERSION, stable-2.0 merged cleanly into master, even
with the duplicate changeset).  Thoughts?

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

Re: Handling of the actively-maintained branches (master, stable-2.0)

[Ludovic Courtès]

Hi Andreas,

Andreas Rottmann <a.rottmann@gmx.at> writes:

> I wonder how this generally should be handled -- I think the most
> appropriate way would be to commit any changes that can go into the
> stable release into stable-2.0 (only), and then, at "convenient times"
> (perhaps always before committing new, not-for-stable stuff to master)
> merge stable-2.0 into master.

Yes, agreed.

> It probably doesn't matter, as git seems to handle duplicate changes
> quite well (just tried, except for a conflict in GUILE-VERSION,
> stable-2.0 merged cleanly into master, even with the duplicate
> changeset).  Thoughts?

Looks like the most convenient approach to me, so let’s do it this way
if nobody disagrees.

Thanks,
Ludo’.

Re: Handling of the actively-maintained branches (master, stable-2.0)

[Andy Wingo]

On Thu 03 Mar 2011 14:16, ludo@gnu.org (Ludovic Courtès) writes:

> Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> I wonder how this generally should be handled -- I think the most
>> appropriate way would be to commit any changes that can go into the
>> stable release into stable-2.0 (only), and then, at "convenient times"
>> (perhaps always before committing new, not-for-stable stuff to master)
>> merge stable-2.0 into master.
>
> Yes, agreed.
>
>> It probably doesn't matter, as git seems to handle duplicate changes
>> quite well (just tried, except for a conflict in GUILE-VERSION,
>> stable-2.0 merged cleanly into master, even with the duplicate
>> changeset).  Thoughts?
>
> Looks like the most convenient approach to me, so let’s do it this way
> if nobody disagrees.

For what it's worth: I agree!

Andy
-- 
http://wingolog.org/