From 1e9a2cbebff77a4716154ccc7cefd0b99c03d602 Mon Sep 17 00:00:00 2001 From: sfan5 Date: Sun, 13 Nov 2022 15:01:34 +0100 Subject: [PATCH] DOCS: update release policy to match reality --- DOCS/release-policy.md | 41 +++++++++++++++++++++++------------------ 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/DOCS/release-policy.md b/DOCS/release-policy.md index 9fb6255cc6..af55d0f5e7 100644 --- a/DOCS/release-policy.md +++ b/DOCS/release-policy.md @@ -1,13 +1,15 @@ Release Policy ============== -Once or twice a month, a new release is cut off of the master branch and is +Once or twice a year, a new release is cut off of the master branch and is assigned a 0.X.Y version number, where X is incremented each time a release contains breaking changes, such as changed options or added/removed features, and Y is incremented if a release contains only bugfixes and other minor changes. Releases are tagged on the master branch and will not be maintained separately. +Patch releases may be made if the amount or severity of bugs justify it, or in +the event of security issues. The goal of releases is to provide Linux distributions with something to package. If you want the newest features, just use the master branch. @@ -31,13 +33,13 @@ While on master: - Create signed tag v0.X.Y. -- Add -UNKNOWN suffix to version in `VERSION` file. - -- Commit changes, push release branch (`release/0.X`) and tag to GitHub. +- Push release branch (`release/0.X`) and tag to GitHub. - Create a new GitHub release using the content of `RELEASE_NOTES` related to the new version. +- Readd -UNKNOWN suffix to version in `VERSION` file. + 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. @@ -45,12 +47,14 @@ then be merged to master so `git describe` will pick up the tag. Release notes template ---------------------- -Here is a template that can be used for writing the `RELEASE_NOTES` file. +Here is a template that can be used for writing the `RELEASE_NOTES` file: ```markdown Release 0.X.Y ============= +This release requires FFmpeg or newer. + Features -------- @@ -59,20 +63,18 @@ New - List of new features -Removed + +Changed ~~~~~~~ - List of removed features -Deprecated + +Removed ~~~~~~~~~~ - List of deprecated features -Behavior --------- - -- List of user-visible changes in behavior Options and Commands -------------------- @@ -82,34 +84,37 @@ Added - List of added options and commands + Changed ~~~~~~~ - List of changed options and commands -Renamed -~~~~~~~ - -- List of renamed options and commands Deprecated ~~~~~~~~~~ - List of deprecated options and commands + Removed ~~~~~~~ - List of removed options and commands + Fixes and Minor Enhancements ---------------------------- - List of fixes and minor enhancements -This listing is not complete. There are many more bug fixes and changes. The -complete change log can be viewed by running `git log ..` in -the git repository. + +This listing is not complete. Check DOCS/client-api-changes.rst for a history +of changes to the client API, and DOCS/interface-changes.rst for a history +of changes to other user-visible interfaces. + +A complete changelog can be seen by running `git log ..` +in the git repository. ``` Note that the "Release 0.X.Y" title should be removed when creating a new GitHub