| 5.28.x | Jun 2020 | Jul 2020 | Aug 5, 2020 | Aug 2020 |
| 5.27.x | May 2020 | Jun 2020 | Jul 1, 2020 | Jul 2020 (tentative ESR) |
| 5.27.x | May 2020 | Jun 2020 | Jul 1, 2020 | Jul 2020 plus [ESR](https://civicrm.org/esr) |
| 5.26.x | Apr 2020 | May 2020 | Jun 3, 2020 | Jun 2020 |
| 5.25.x | Mar 2020 | Apr 2020 | May 6, 2020 | May 2020 |
| 5.24.x | Feb 2020 | Mar 2020 | Apr 1, 2020 | Apr 2020 |
...
...
@@ -47,8 +57,6 @@ index of release-plans and the release invitations.
| 5.1.x | Mar 2018 | Apr 2018 | May 2, 2018 | May 2018 |
| 5.0.x | Feb 2018 | Mar 2018 | Apr 4, 2018 | Apr 2018 |
Unless stated otherwise, months are generally bounded by the first Wed. Thus, development in May 2018 actually lasts from 2-May-18 to 6-Jun-18.
## Release Lifecycle
Each period has a different policy on accepting changes:
...
...
@@ -69,6 +77,20 @@ Each period has a different policy on accepting changes:
(*For historical planning information from 4.7.x cycles, see [4.7-release-history.md](doc/4.7-release-history.md).*)
## Timing
General rules:
* Months are bounded by the first Wed. Thus, development in May 2018 actually lasts from 2-May-18 to 6-Jun-18.
* Release dates are usually construed in US/Pacific time. Thus, a release on 7-Apr-21 in US/Pacific time may
be 8-Apr-21 in AU/Eastern time.
* On a designated *Release Date*, all three main branches (development, RC, stable) will usually be updated on the same day.
Those are not absolute rules -- exceptions may arise a couple times a year. For example:
* If the first Wed of a month coincides with major holiday (e.g. New Years Day), then it could be moved.
* If there is an important patch near completion, the new RC could be delayed an extra day.
## Philosophy
Reviewing and testing are natural, important, on-going parts of software-development, but they generally cannot be done by the original developer. All developers have a shared interest in having their changes reviewed by a neutral and competent party. The goal of the release-cycle is to match-up developers who are willing to check each other's work, and to bring in feedback from non-developers to improve quality assurance.
