[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release schedule - to branch or not to branch

From: Tobias
Subject: Re: Release schedule - to branch or not to branch
Date: Mon, 31 Mar 2003 22:58:20 +0200
User-agent: KMail/1.5.1

vital discussion so far,
but now, that everybody argues against braches, i think, i may speak up.

> I agree with this - I have often argued that branches have never been
> particularly useful for GNUstep - they seem to be mostly wasting our time.
i agree.

consider a user, that wants to test, but needs a quiet stable desktop.
he does not follow mailing lists, nor does he regularly look at the website.

at present:
he will do a `cvs up` in his checkout.
nothing will happen, because his branch is way too old. 
(say, an old release branch)
he will have to search mailing lists, read the website, do something!
get the right branch and update (with the right branch).
this may well distract the user. he will think about following gnome 
development ;)

this is, ehm, suboptimal.
this is why i dont like branches.

but remember, he wanted a stable desktop, without any incompatibilities 
currently being tested.
so he wont want to follow HEAD.
you may say, that it was advertised on -discuss, that it was not safe to 
upgrade now. you are right!
but he does not follow mailing lists.

i propose to maintain (*) exactly 2 branches.
one, say -current (or HEAD), to test new stuff.
one, say -stable or -release, which will become the next stable release.

this is why i like branches.

*) i really mean maintain, we should be able to backport *proven* *stable* 
code from -current.

sorry, for being a bit verbose.
but i hope, this does not perish into nonentity.

ps: yes, i am influenced by *bsd's development model.
but i think it is worth thinking about it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]