procyberian/emacs
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

; * 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
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 is merged into the master, using the gitmerge function described in
admin/notes/git-workflow. admin/notes/git-workflow.
If you are fixing a bug that exists in the current release, be sure to If you are fixing a bug that exists in the current release, you should
commit it to the release branch; it will be merged to the master generally commit it to the release branch; it will be merged to the
branch later by the gitmerge function. 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) Documentation fixes (in doc strings, in manuals, in NEWS, and in
should always go to the release branch, if the documentation to be comments) should always go to the release branch, if the documentation
fixed exists and is relevant to the release-branch codebase. Doc to be fixed exists and is relevant to the release-branch codebase.
fixes are always considered "safe" -- even when a release branch is in Doc fixes are always considered "safe" -- even when a release branch
feature freeze, it can still receive doc fixes. is in feature freeze, it can still receive doc fixes.
When you know that the change will be difficult to merge to the 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 master (e.g., because the code on master has changed a lot), you can