Re: fast-forward only policy

[Felipe Contreras <felipe contreras gmail com>]

On Tue, May 5, 2009 at 2:35 PM, Vincent Untz <vuntz gnome org> wrote:
> Le mardi 05 mai 2009, à 01:51 +0300, Felipe Contreras a écrit :
>> On Tue, May 5, 2009 at 1:21 AM, Marc-André Lureau
>> <marcandre lureau gmail com> wrote:
>> > Hi
>> >
>> > On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras
>> > <felipe contreras gmail com> wrote:
>> >> [...] what is the point of having 'project' in the branch
>> >> name? Branches are per-repository, so you would never have a non
>> >> 'gtk-' branch in the GTK+ repo.
>> >>
>> >
>> > Not "project" but really "[project]-[MAJOR]-[MINOR]"..
>>
>> Yes, I meant why "project-major-minor" (gtk-2-17) when you already
>> know 'project'. What information would be lost with a '2-17' branch
>> name?
>
> Why should we change a policy we had for ages and which works fine?

Because you just switched your SCM and it's the best time to do that?

> Note that for GNOME modules specifically, having gnome-2-26 is important
> since it makes it clear that this is a branch for GNOME 2.26. Even if
> gvfs is at version 1.2, for example.

I'm not sure the guidelines I've read mention that usage, but in any
case that's not a compelling argument; you can still have branches
'1-2' and 'gnome-2-26'.

>> >> In fact, AFAIK at any given time GNOME projects have at most two lines
>> >> of development. When GTK+ 2.17 is released, work on 2.16 is continued,
>> >> but not on 2.15, so what is the point of keeping the 'gtk-2-15'
>> >> branch? (or gtk-2-14) In reality you only have a 'master' and a
>> >> sometimes a 'devel' branch.
>> >>
>> >
>> > You should read http://live.gnome.org/MaintainersCorner#branches
>>
>> Just read it. I'm not sure exactly what you wanted to highlight.
>>
>> > Stable branches are useful! Most projects have mostly stable branches, afaik.
>>
>> Hmm, I'm not sure we are talking about the same thing. My
>> understanding is that in most projects there's only one 'stable'
>> branch, as in "the most stable branch we have at the moment". Some
>> projects have 'devel' ("we are currently working on it, but it's not
>> that sable") and some have 'next' ("this is what you'll get on the
>> next big release, it's probably stable enough").
>>
>> After reading that link (and some email searching), I think you do a
>> "branching" process where you create a branch for the stable release
>> and keep the development on the "master" branch. In that case I would
>> suggest instead of creating a "gtk-2-16" branch just use a "stable"
>> branch, which will jump (or merge) from what you now call "gtk-2-14"
>> to "gtk-2-16" when you do this branching process. The "gtk-2-14"
>> commits won't be lost as long as they are tagged.
>
> Some people are using the old stable branches, so we definitely want to
> keep them. While GNOME only officially supports only one stable branch
> at any time (which is what you seem to propose), enabling people to do
> more than that is a good thing.

As I said, the commits won't be lost, people that want to work on an
old version can do that:

git checkout -b my-incredibly-old-branch LIBGNOME_2_0_0

Tags and branches are simply commit references (pointers); tags are
for fixed targets, while branches are for moving ones. If the branch
is not going to move any more there isn't much point in keeping it,
specially when there's a tag pointing to the same commit.

-- 
Felipe Contreras