Re: policy for release branch

[Daniel J Sebald]

Robert T. Short wrote:

> The other serious issue is maintaining two source trees.  How often should
> we make a major release?  That is, a release with new features that might
> break some existing code.  Certainly when there are new features that 
> really
> enhance the octave experience.  Probably when the pain of managing
> two sets of patches gets to be more trouble than it is worth.


I wonder if branching a version would best be done with some type of bug 
reporting tool in order to keep things straight.

It only makes sense to maintain a version branch so long as there is an 
audience for that branch or there isn't going to be a new release any time 
soon.  I suspect that as new versions appear, older ones will see less traffic. 
 It would be nice if there were a temporal record of the downloads for a 
version.  As time goes on, I'd expect an increase in the number of downloads, a 
peak and then gradual fall off.  (And it would be interesting to see how the 
old version download traffic correlates with the appearance of a new version.)  
When it looks like the download traffic has  dropped off, then it might be good 
to freeze the old version and somehow indicate that no bugs will be addressed 
for the old version anymore.

As for patches, I'd say fix the bug in the old version if someone reports a bug 
for that particular release.  Then apply the patch/changeset to the trunk.  
Sometimes the patch will need some manual merge to make it work on the trunk.  
If that gets to be too often, then perhaps it is time for a new release.

Dan