commit 6db2e59f2057951d4a9bbd3dfc15509eb9afa51b Author: teor teor@torproject.org Date: Fri Apr 3 22:06:27 2020 +1000

doc: Minor restructure for Release Lifecycle

* make end and beginning of life into second-level sections * write an intro for beginning * tweak intro for end --- doc/HACKING/ReleaseSeriesLifecycle.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/doc/HACKING/ReleaseSeriesLifecycle.md b/doc/HACKING/ReleaseSeriesLifecycle.md index 4d223af18..44a226fd9 100644 --- a/doc/HACKING/ReleaseSeriesLifecycle.md +++ b/doc/HACKING/ReleaseSeriesLifecycle.md @@ -1,9 +1,14 @@ -## End of Life on an old release series +# Release Series Lifecycle + + +## End Of Life On An Old Release Series

Here are the steps that the maintainer should take when an old Tor release -series reaches End of Life. Note that they are _only_ for an entire series -that has reached its planned EOL: they do not apply to security-related -deprecations of individual versions. +series reaches End of Life. + +Note that they are _only_ for an entire series that has reached its planned +EOL: they do not apply to security-related deprecations of individual +patch versions.

### 1. Preliminaries @@ -17,7 +22,7 @@ deprecations of individual versions. packagers.

-### 2. On the day +### 2. On The Day

1. Open tickets to remove the release from: - the jenkins builds @@ -72,8 +77,13 @@ deprecations of individual versions. 12. Finally, make sure this document is up to date with our latest process.

+## Starting A New Release Series + +Here are the steps that the maintainer should take to start new maint and +release branches for a stable release.

-### 3. Starting a new release series. +Note that they are _only_ for an entire series, when it first becomes stable: +they do not apply to security-related patch release versions.

(Ideally, do this immediately after a release.)