diff --git a/DOCS/release-policy.md b/DOCS/release-policy.md index 322e9a010a..5a1f961f37 100644 --- a/DOCS/release-policy.md +++ b/DOCS/release-policy.md @@ -1,64 +1,106 @@ Release Policy ============== -Every few months, a new release is cut off of the master branch and is assigned -a 0.X.0 version number. +Once or twice a month, 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. -As part of the maintenance process, minor releases are made, which are assigned -0.X.Y version numbers. Minor releases contain bug fixes only. They never merge -the master branch, and no features are added to it. Only the latest release is -maintained. +There is only one release branch that keeps track of the latest version and +will not be maintained separately. -The goal of releases is to provide stability and an unchanged base for the sake -of Linux distributions. If you want the newest features, just use the master -branch, which is stable most of the time, except sometimes, when it's not. +The goal of releases is to provide Linux distributions with something to +package. If you want the newest features, just use the master branch. +We try our best to keep it deployable at all times. Releases other than the latest release are unsupported and unmaintained. Release procedure ----------------- -- Create branch release/0.X or cherry-pick commits to the relevant branch. +- Merge master into branch release/current. -- Create and/or update the ``RELEASE_NOTES`` file. +- Create and/or update the `RELEASE_NOTES` file. -- Create and/or update the ``VERSION`` file. +- Create and/or update the `VERSION` file. -- Update ``DOCS/client-api-changes.rst`` (on major releases). +- Update `DOCS/client-api-changes.rst` (on major releases). - Create tag v0.X.Y. - Push branch and tag to GitHub. -- Create a new GitHub release using the content of ``RELEASE_NOTES`` related to +- Create a new GitHub release using the content of `RELEASE_NOTES` related to the new version. 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 ============= -Changes -------- +Features +-------- -- List of changes. +New +~~~ -Bug fixes ---------- +- List of new features -- List of bug fixes. +Removed +~~~~~~~ -New features ------------- +- List of removed features -- List of new features. +Deprecated +~~~~~~~~~~ + +- List of deprecated features + +Behavior +-------- + +- List of user-visible changes in behavior + +Options and Commands +-------------------- + +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 +complete change log can be viewed by running `git log ..` in the git repository. ``` @@ -66,6 +108,6 @@ 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 +`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.