Ticket #32 (closed todo: duplicate)
Document Parrot backwards compatability policy
| Reported by: | whiteknight | Owned by: | allison |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.0 |
| Component: | docs | Version: | trunk |
| Severity: | low | Keywords: | TODO |
| Cc: | Language: | ||
| Patch status: | Platform: |
Description
From RT#36249. We need to document how we guarantee/manage backwards compatibility.
--Andrew Whitworth
According to Allison in the RT ticket:
And, we have discussed it considerably. The most likely scenario so far is:
- Yearly major release (1.0, 2.0, 3.0...), which may contain substantial API changes.
- Half-yearly minor release (1.5, 2.5, 3.5...), which may contain minor API changes, and deprecation notices for the next major release.
- Regular (two/three month?) point releases (1.x.x, 2.x.x...) primarily bug and security fixes, which will contain no API deletions, but may contain minor API additions, and deprecation notices for the next major or minor release.
This continues our time-based release policy, which has worked well for the development release process. Features that don't make it into one major or minor release get rolled into the branch for the next major or minor release, so we don't have an insane rush to cram features in just before a release.
