[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
policy for pushing changesets
From: |
John W. Eaton |
Subject: |
policy for pushing changesets |
Date: |
Mon, 11 Apr 2011 21:44:03 -0400 |
On 11-Apr-2011, Ben Abbott wrote:
| John/Rik,
|
| Going forward, what is the policy regarding pushing changes to the stable and
default branches?
I posted the following info, but it was in a thread called "Release
3.4.1". I should have started a new thread.
[...] 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.
| For example, what should be done with the getappdata changeset?
|
| https://savannah.gnu.org/bugs/?33012
If it fixes a bug and doesn't introduce a binary incompatibility
(changes to .m files usually can't cause trouble that way) and it is
not a risky change, then apply it to stable.
Thanks,
jwe
- policy for pushing changesets, Ben Abbott, 2011/04/11
- policy for pushing changesets,
John W. Eaton <=
- Re: policy for pushing changesets, Ben Abbott, 2011/04/11
- Re: policy for pushing changesets, Jordi GutiƩrrez Hermoso, 2011/04/12
- Re: policy for pushing changesets, John W. Eaton, 2011/04/12
- Re: ChangeLog entries and hg, Rik, 2011/04/12
- Re: ChangeLog entries and hg, John W. Eaton, 2011/04/12
- Re: ChangeLog entries and hg, Ben Abbott, 2011/04/12
- Re: ChangeLog entries and hg, Jordi GutiƩrrez Hermoso, 2011/04/12
- Re: ChangeLog entries and hg, Rik, 2011/04/12
- Re: ChangeLog entries and hg, John W. Eaton, 2011/04/12
- Re: ChangeLog entries and hg, John W. Eaton, 2011/04/19