|
|
|
# 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. |
