DOCS: update release policy

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 <start>..<end>`` in
+complete change log can be viewed by running `git log <start>..<end>` 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.