[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: Alexander Malmberg
Subject: Re: Release schedule - to branch or not to branch
Date: Tue, 01 Apr 2003 01:26:48 +0200

Tobias wrote:
> 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.
> somehow...
> 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 ;)

The frequent semi-stable releases would solve this. In addition to
normal version tag, we would have a moving LATEST_SEMISTABLE tag. You
only need to specify this once (eg. cvs update -r LATEST_SEMISTABLE),
and when you update (a plain "cvs update -Pd" will do), you will get the
latest tagged semi-stable version.

(It might be a good idea to maintain such a tag even if we don't have
actual semi-stable releases.)

> 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.

In the very long term, this might be a good idea, but currently, I think
there is too much active development going on for a stable branch to be
realistic. Maintaining it would be too much work, and I don't think
there are many who are willing to do it.

> sorry, for being a bit verbose.
> but i hope, this does not perish into nonentity.
> ~ibotty
> ps: yes, i am influenced by *bsd's development model.
> but i think it is worth thinking about it.

- Alexander Malmberg

reply via email to

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