gnustep-dev
[Top][All Lists]
Advanced

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

Re: Release schedule - to branch or not to branch


From: Willem Rein Oudshoorn
Subject: Re: Release schedule - to branch or not to branch
Date: 01 Apr 2003 23:55:07 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Alexander Malmberg <address@hidden> writes:


> The frequent semi-stable releases would solve this. 

Well, I am not sure if this really helps.  I find it a little
hard to judge when something is "relatively" stable and when it
is not.  

> 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 seems a nice idea, but I fear it will not increase the stability
of the final releases.

What I think is best is some scheme that works as follows. 

* Normal state, between releases and not close to a release.
  Then there is only one branch.  "cvs update" will give this
  branch.

* State before release.
  Two branches.  The "to be" branch and the "development" 
  branch.  "cvs update" will give the "to be" branch, so
  this one will be tested.  Write permissions for the 
  "to be" branch will be severly limited.  Most new development
  will take place on the "development" branch.

However there are two problems:

A - Developers will most likely switch to "development" branch,
    limiting the testing benefit.
B - It is not easily done with cvs.


Having said this, a technical solution will not solve this.
Unless people find it really important to bring out 
stable releases no technical measure will work.

Personally, I will/am be using `base' in the course of my work.
So I find stable base releases important.  This becomes really
important in a few months time.  So for the next base release
I would prefer a release branch.  Around that time I volunteer
maintain the release branch for base. 


Wim Oudshoorn.




reply via email to

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