mirror/emacs
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/emacs.git synced 2025-01-30 19:53:09 +00:00
Code Issues Releases Activity

; * CONTRIBUTE: Clarify rules for committing to release branches.

Browse Source
This commit is contained in:
Eli Zaretskii 2018-11-30 13:07:40 +02:00
parent a89dbe2af8
commit cc3ad9a3d1
1 changed files with 16 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
CONTRIBUTE
View File

@ -287,15 +287,23 @@ the current release branch. Periodically, the current release branch
is merged into the master, using the gitmerge function described in
admin/notes/git-workflow.
If you are fixing a bug that exists in the current release, be sure to
commit it to the release branch; it will be merged to the master
branch later by the gitmerge function.
If you are fixing a bug that exists in the current release, you should
generally commit it to the release branch; it will be merged to the
master branch later by the gitmerge function. However, when the
release branch is for Emacs version NN.2 and later, or when it is for
Emacs version NN.1 that is in the very last stages of its pretest,
that branch is considered to be in a feature freeze: only bug fixes
that are "safe" or are fixing major problems should go to the release
branch, the rest should be committed to the master branch. This is so
to avoid destabilizing the next Emacs release. If you are unsure
whether your bug fix is "safe" enough for the release branch, ask on
the emacs-devel mailing list.
Documentation fixes (in doc strings, in manuals, and in comments)
should always go to the release branch, if the documentation to be
fixed exists and is relevant to the release-branch codebase. Doc
fixes are always considered "safe" -- even when a release branch is in
feature freeze, it can still receive doc fixes.
Documentation fixes (in doc strings, in manuals, in NEWS, and in
comments) should always go to the release branch, if the documentation
to be fixed exists and is relevant to the release-branch codebase.
Doc fixes are always considered "safe" -- even when a release branch
is in feature freeze, it can still receive doc fixes.
When you know that the change will be difficult to merge to the
master (e.g., because the code on master has changed a lot), you can