New Release Policy authored by David Goulet's avatar David Goulet


Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
# Release Policy
This policy is a draft: we haven't decided when we will try it out.
See the [[backport process](./org/teams/NetworkTeam/Backports|)] for how we handle backport tickets.
Previously, we used to follow a strict 6 months release schedule but we do not
anymore because the majority of our engineering resources have now shifted to
[arti](https://gitlab.torproject.org/tpo/core/arti) and thus we are now
releasing `tor.git` on a "when we can and it is ready" basis.
## Current Process
At the moment, here's how we do releases:
• If we have an active alpha series, put out an alpha every few weeks.
• Put out a stable release every 1-2 months.
• Put out oldstable and LTS releases as needed.
https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsNetworkTeam/Notes/StableMaintainer#CurrentProcess
## Potential Changes
### Regular Release Dates
Do we want to schedule our stable releases on set dates?
Here's one possible schedule:
* alpha release: every 2 weeks, on a Wednesday
* we expect alpha releases to be more irregular: we only do them as needed
* early in the stable release: check if a new release is needed, every 4 weeks, on a Wednesday
* maintenance releases: as needed, but usually at the same time as a stable or alpha release
* includes oldstable and LTS releases
I chose Wednesday because it's the middle of the week. Friday failures can lead to weekend work, and some people's Mondays and Fridays overlap with other people's weekends.
### Alpha To Stable
Suggested policies:
* we don't do oldstable and LTS releases, unless there is an important, user-visible change
* we can skip a release if the changes are trivial (or there are no changes)
* trivial changes are any change that users won't notice, or won't want to upgrade if they knew about it
* if a change doesn't need a separate reviewer, it's probably a trivial change
* we can do a release early for urgent fixes. After an urgent fix, we reschedule future releases every 2-4 weeks from that date
* we can reschedule releases if people are on leave
Depending on active development and our roadmap, we try to regurlarly do
**alpha** releases every few weeks over usually several months.
### Mini-Freezes
Once we are satisfied with an alpha, we then transition into a **release
candidate (rc)** for which no more features are merged. That process usually
takes couple weeks at most depending on the stability.
We will declare a soft freeze for some amount of time before each stable release date, and say that nothing inessential gets backported in that time.
Finally, we release a **stable** when we believe it has been tested enough.
Once the stable is released, we open the merge window for the next release
series.
Freezes will start on the previous Wednesday.
### Old Stable
If we discover urgent fixes, we should delay the release another week, so the new fixes get some nightly testing.
Once a stable series becomes old stable, that is a new stable was released,
there are little very little chances that we'll do another oldstable release
for that series.
Alpha releases don't have mini-freezes, but we should avoid merging any major changes in the day or two before the release.
We will in case we merge fixes as described by our [support policy](./SupportPolicy).
### Transitioning between Early Stable and Maintenance
### End of Life
Every 4 weeks, we check if we need to do an early stable release.
If we go 8 weeks without doing an early stable release, we transition
that stable release to the stable maintainers.
Once a release series reach that state, nothing is done on it even in case of
critical security issues.
That is, if a stable release series requires lots of urgent patches,
we keep it with the master maintainers until those bugs are fixed.
\ No newline at end of file
Furthermore, directory authorities will reject EOL versions from the
consensus.