diff options
| author | Eli Zaretskii | 2018-11-30 13:07:40 +0200 |
|---|---|---|
| committer | Eli Zaretskii | 2018-11-30 13:07:40 +0200 |
| commit | cc3ad9a3d1b278852336265e0505e82cc5453778 (patch) | |
| tree | e547404991872b3519088edda16d13b2d378c838 | |
| parent | a89dbe2af8a8a23e07c1e5cb988f067fe08111d9 (diff) | |
| download | emacs-cc3ad9a3d1b278852336265e0505e82cc5453778.tar.gz emacs-cc3ad9a3d1b278852336265e0505e82cc5453778.zip | |
; * CONTRIBUTE: Clarify rules for committing to release branches.
| -rw-r--r-- | CONTRIBUTE | 26 |
1 files changed, 17 insertions, 9 deletions
diff --git a/CONTRIBUTE b/CONTRIBUTE index 0b68052a0cd..efd4bf10ecd 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE | |||
| @@ -287,15 +287,23 @@ the current release branch. Periodically, the current release branch | |||
| 287 | is merged into the master, using the gitmerge function described in | 287 | is merged into the master, using the gitmerge function described in |
| 288 | admin/notes/git-workflow. | 288 | admin/notes/git-workflow. |
| 289 | 289 | ||
| 290 | If you are fixing a bug that exists in the current release, be sure to | 290 | If you are fixing a bug that exists in the current release, you should |
| 291 | commit it to the release branch; it will be merged to the master | 291 | generally commit it to the release branch; it will be merged to the |
| 292 | branch later by the gitmerge function. | 292 | master branch later by the gitmerge function. However, when the |
| 293 | 293 | release branch is for Emacs version NN.2 and later, or when it is for | |
| 294 | Documentation fixes (in doc strings, in manuals, and in comments) | 294 | Emacs version NN.1 that is in the very last stages of its pretest, |
| 295 | should always go to the release branch, if the documentation to be | 295 | that branch is considered to be in a feature freeze: only bug fixes |
| 296 | fixed exists and is relevant to the release-branch codebase. Doc | 296 | that are "safe" or are fixing major problems should go to the release |
| 297 | fixes are always considered "safe" -- even when a release branch is in | 297 | branch, the rest should be committed to the master branch. This is so |
| 298 | feature freeze, it can still receive doc fixes. | 298 | to avoid destabilizing the next Emacs release. If you are unsure |
| 299 | whether your bug fix is "safe" enough for the release branch, ask on | ||
| 300 | the emacs-devel mailing list. | ||
| 301 | |||
| 302 | Documentation fixes (in doc strings, in manuals, in NEWS, and in | ||
| 303 | comments) should always go to the release branch, if the documentation | ||
| 304 | to be fixed exists and is relevant to the release-branch codebase. | ||
| 305 | Doc fixes are always considered "safe" -- even when a release branch | ||
| 306 | is in feature freeze, it can still receive doc fixes. | ||
| 299 | 307 | ||
| 300 | When you know that the change will be difficult to merge to the | 308 | When you know that the change will be difficult to merge to the |
| 301 | master (e.g., because the code on master has changed a lot), you can | 309 | master (e.g., because the code on master has changed a lot), you can |