Re: stable and default branches

[Rik]

On 04/07/2011 08:28 AM, John W. Eaton wrote:
> On  6-Apr-2011, Rik wrote:
> 
> | This sounds good to me.  When do you want to attempt the merge and split?
> | We can certainly hold off committing changes around that time so that the
> | new patches make it on to the correct branch.
> 
> Thinking about it a little more, is there really any need to merge the
> 3.4.x branch with default?  With the exception of the patches that set
> the version number for the release, I think every patch on the release
> branch was transplanted from default, and in all cases, any conflicts
> would just be resolved by using the code from default, not the release
> branch.  So we might as well just abandon the 3.4.x branch and split
> stable from the tip of the default branch.
> 
> Are there any objections to doing that now?
4/7/11

John,

I went ahead and introduced a stable branch to the repo and checked in a
documentation change on it (changeset: 6a4e042b6114).

As a quick guide for others, use 'hg update <default | stable>' to switch
between branches.  I'm finding it easier to maintain one directory tree for
each branch rather than switching back and forth in the same tree and
causing unnecessary rebuilds.  My setup is a directory called "octave-doc"
which is set to the "stable" branch and directory "octave-dev" set to the
"default" branch.  Once the branch has been set 'hg pull ; hg update' will
do its normal job of getting changes and updating you to the tip of your
current branch.

--Rik
> 
> If not, I can do it, then we can start using the new rules for commits
> to stable and default:
> 
>   * Bug fixes that do not introduce binary incompatibility in the
>     current release series and improvements in documentation for the
>     current release should be applied to the stable branch.
> 
>   * All other changes (code refactoring, new functions, new features,
>     or documentation for them, and everything else) should go on the
>     default branch.
> 
>   * The stable branch will be merged with the default branch.  This
>     can happen any time.  If you make a change that is likely to
>     generate conflicts, it might be best if you perform the merge
>     since you will probably be in the best position to determine how
>     to resolve the conflict as you will know the intent of your patch.
> 
> So unless you are fixing a bug or updating documentation that applies
> to the current stable release, yous should be working with default.
> We should be relatively conservative about what changes go on stable
> so that stable becomes more reliable over time.  The stable branch is
> not the place for large or risky changes.  If necessary, we can always
> transplant changes from default to stable.
> 
> In any case, if you are unsure of what to do for a particular patch,
> ask before committing the change.
> 
> jwe
>