Skip to content
The Tor Project
New Release Policy
Apr 22, 2022
Hide whitespace changes
View page @
# Release Policy
This policy is a draft: we haven't decided when we will try it out.
] 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
and thus we are now
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.
## 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
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
releases every few weeks over usually several months.
Once we are satisfied with an alpha, we then transition into a
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
when we believe it has been tested enough.
Once the stable is released, we open the merge window for the next release
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 da
two before the release
We will in case we merge fixes as described b
Transitioning between Early Stable and Maintenanc
End of Lif
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