octave-maintainers
[Top][All Lists]
Advanced

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

Re: Release 3.4.1


From: John W. Eaton
Subject: Re: Release 3.4.1
Date: Thu, 7 Apr 2011 11:28:47 -0400

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?

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


reply via email to

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