diff options
Diffstat (limited to 'DOCS/release-policy.md')
| -rw-r--r-- | DOCS/release-policy.md | 33 |
1 files changed, 25 insertions, 8 deletions
diff --git a/DOCS/release-policy.md b/DOCS/release-policy.md index af55d0f5e7..23bc48befd 100644 --- a/DOCS/release-policy.md +++ b/DOCS/release-policy.md @@ -26,8 +26,13 @@ While on master: - Update the `VERSION` file. -- Update `DOCS/client-api-changes.rst` and `DOCS/interface-changes.rst` - (in particular, update the last version numbers if necessary) +- Update `DOCS/client-api-changes.rst` (in particular, update the last version + number if necessary) + +- Run `TOOLS/gen-interface-changes.py` to refresh `DOCS/interface-changes.rst`, + edit manually as necessary. + +- Delete all `.txt` files in the `DOCS/interface-changes` directory except for `example.txt`. - Create signed commit with changes. @@ -44,6 +49,9 @@ If necessary (to e.g. exclude commits already on master), the release can be done on a branch with different commit history. The release branch **must** then be merged to master so `git describe` will pick up the tag. +This does not apply to patch releases, which are tagged directly on the +`release/0.X` branch. The master branch always remains at v0.X.0. + Release notes template ---------------------- @@ -67,13 +75,13 @@ New Changed ~~~~~~~ -- List of removed features +- List of changed features Removed -~~~~~~~~~~ +~~~~~~~ -- List of deprecated features +- List of removed features Options and Commands @@ -117,10 +125,19 @@ A complete changelog can be seen by running `git log <start>..<end>` in the git repository. ``` -Note that the "Release 0.X.Y" title should be removed when creating a new GitHub -release. - When creating a new point release its changes should be added on top of the `RELEASE_NOTES` file (with the appropriate title) so that all the changes in the current 0.X branch will be included. This way the `RELEASE_NOTES` file can be used by distributors as changelog for point releases too. + +The changelog of lists all changes since the last release, including those +that have been backported to patch releases already. + +Some additional advice: +- Especially for features, try to reword the messages so that the user-visible + change is clear to the reader. But don't simplify too much or be too verbose. +- It often makes sense to merge multiple related changes into one line +- Changes that have been made and reverted within the same release must not + appear in the changelog +- Limit the "Options and Commands" section to relevant changes +- When filling in the GitHub release, remove the "Release 0.X.Y" heading |