|
5 | 5 | Release Notes
|
6 | 6 | =============
|
7 | 7 |
|
| 8 | +This project loosly follows Semantic Versioning (``major.minor.patch``), with |
| 9 | +the exception that changes are allowed in minor releases as long as the change |
| 10 | +is necessary to match documentation, specification or expectation. |
| 11 | +In other words: Bugfixes do not count as backward incompatible changes, even if |
| 12 | +they technically change something from *incorrect* to *correct* and may break |
| 13 | +applications that rely on *incorrect*, *undefined* or *undocumented* behavior. |
| 14 | + |
| 15 | +As long as the major version is still ``0.x``, breaking API changes are also |
| 16 | +allowed in minor releases, but we try our best to provide fallbacks and emit |
| 17 | +deprecation warnings for at least one minor release circle. |
| 18 | + |
| 19 | +.. rubric:: How to upgrade |
| 20 | + |
| 21 | +* Upgrade to the most recent patch release available for your current minor |
| 22 | + release. (e.g. ``0.12.3`` to ``0.12.25``) |
| 23 | +* Read the release notes for the next minor release, run your tests and fix all |
| 24 | + deprecation warnings. |
| 25 | +* Upgrade to the next minor release (e.g. ``0.12.25`` to ``0.13.2``), run test |
| 26 | + again, fix all warnings and continue. |
| 27 | + |
| 28 | +.. rubric:: Support for old releases |
| 29 | + |
| 30 | +Bugs and security issues are usually fixed in the latest minor release of the |
| 31 | +two most recent major releases (named stable and old-stable). With each new major |
| 32 | +release, stable becomes old-stable and the old old-stable will no longer receive |
| 33 | +regular updates. LTS releases (e.g. 0.12) are an exception. Those will continue |
| 34 | +to receive updates on a best-effort basis. |
| 35 | + |
8 | 36 | Release 0.14 (in development)
|
9 | 37 | =============================
|
10 | 38 |
|
|
0 commit comments