Clarify semantics for our supported releases
Given that our defacto LTS release (3.3.x) is expiring in march 2019, I'd like to make a proposal for further clarifying our current release message:
- We will have a release branch supported for 2 years, tagged as LTS (long-term-support); there can be only one such branch
- We may have a release branch continuously updated which is tagged as next.
When the support time for current LTS release expires, the next branch becomes LTS.
Properties of the LTS release branch:
- Periodic releases will be made during that time on a bi-monthly basis (could be skipped if no significant changes are accumulated),
- Features can enter that release according to the rules in
Introducing new features / modifying behavior
from !816 (merged). - Security fixes will enter that release if above the severity level high according to CVSS; may enter on moderate or lower.
- No incompatible ABI or API changes
- New features added when deemed important but do not modify the default behavior (more details will be in CONTRIBUTIONS.md)
Properties of the next release branch:
- Periodic releases will be made during that time on a bi-monthly basis (could be skipped if no significant changes are accumulated),
- No incompatible ABI or API changes (see CONTRIBUTIONS.md) for details; unless there is a wide agreement/consensus for ABI breakage
- If the ABI breaks the current LTS release expiration is renewed to maximum, to allow time to distributions to migrate
- The default behavior of the library can be change, as long as the changes are included in the documentation (section upgrade of manual)