andpp/mopidy
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs: Add section on semantic versioning

Browse Source 
Fixes #1050
This commit is contained in:
Stein Magnus Jodal 2015-03-18 23:40:03 +01:00
parent dc982cd880
commit 4692e73054
1 changed files with 26 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
docs/versioning.rst
View File

@ -2,22 +2,36 @@
Versioning Versioning
********** **********
Mopidy uses `Semantic Versioning <http://semver.org/>`_, but since we're still Mopidy follows `Semantic Versioning <http://semver.org/>`_. In summary this
pre-1.0 that doesn't mean much yet. means that our version numbers have three parts, MAJOR.MINOR.PATCH, which
change according to the following rules:
- When we *make incompatible API changes*, we increase the MAJOR number.
- When we *add features* in a backwards-compatible manner, we increase the
MINOR number.
- When we *fix bugs* in a backwards-compatible manner, we increase the PATCH
number.
The promise is that if you make a Mopidy extension for Mopidy 1.0, it should
work unchanged with any Mopidy 1.x release, but probably not with 2.0. When a
new major version is released, you must review the incompatible changes and
update your extension accordingly.
Release schedule Release schedule
================ ================
We intend to have about one feature release every month in periods of active We intend to have about one feature release every month in periods of active
development. The feature releases are numbered 0.x.0. The features added is a development. The features added is a mix of what we feel is most
mix of what we feel is most important/requested of the missing features, and important/requested of the missing features, and features we develop just
features we develop just because we find them fun to make, even though they may because we find them fun to make, even though they may be useful for very few
be useful for very few users or for a limited use case. users or for a limited use case.
Bugfix releases, numbered 0.x.y, will be released whenever we discover bugs Bugfix releases will be released whenever we discover bugs that are too serious
that are too serious to wait for the next feature release. We will only release to wait for the next feature release. We will only release bugfix releases for
bugfix releases for the last feature release. E.g. when 0.14.0 is released, we the last feature release. E.g. when 1.2.0 is released, we will no longer
will no longer provide bugfix releases for the 0.13 series. In other words, provide bugfix releases for the 1.1.x series. In other words, there will be just
there will be just a single supported release at any point in time. This is to a single supported release at any point in time. This is to not spread our
not spread our limited resources too thin. limited resources too thin.