* Handling of the actively-maintained branches (master, stable-2.0)
@ 2011-03-02 23:51 Andreas Rottmann
2011-03-03 13:16 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Rottmann @ 2011-03-02 23:51 UTC (permalink / raw)
To: Guile Development
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/>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Handling of the actively-maintained branches (master, stable-2.0)
2011-03-02 23:51 Handling of the actively-maintained branches (master, stable-2.0) Andreas Rottmann
@ 2011-03-03 13:16 ` Ludovic Courtès
2011-03-09 22:06 ` Andy Wingo
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2011-03-03 13:16 UTC (permalink / raw)
To: guile-devel
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’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Handling of the actively-maintained branches (master, stable-2.0)
2011-03-03 13:16 ` Ludovic Courtès
@ 2011-03-09 22:06 ` Andy Wingo
0 siblings, 0 replies; 3+ messages in thread
From: Andy Wingo @ 2011-03-09 22:06 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guile-devel
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-03-09 22:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-02 23:51 Handling of the actively-maintained branches (master, stable-2.0) Andreas Rottmann
2011-03-03 13:16 ` Ludovic Courtès
2011-03-09 22:06 ` Andy Wingo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).