tor

commit 6db2e59f2057951d4a9bbd3dfc15509eb9afa51b
parent 0f10ddaa29366df56c63eeeb95e52c4a1fa71cd1
Author: teor <teor@torproject.org>
Date:   Fri,  3 Apr 2020 22:06:27 +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

Diffstat:
M
doc/HACKING/ReleaseSeriesLifecycle.md
 | 
22
++++++++++++++++------

1 file changed, 16 insertions(+), 6 deletions(-)
diff --git 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.)