commit 455ea05bdfb841bfb84acdf464f497996824cd7a
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Fri Feb 14 08:47:17 2020 -0500
Rename EndOfLifeTor to ReleaseSeriesLifecycle; expand it.
Closes ticket 30917.
---
.../{EndOfLifeTor.md => ReleaseSeriesLifecycle.md} | 50 +++++++++++++++++++++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/doc/HACKING/EndOfLifeTor.md b/doc/HACKING/ReleaseSeriesLifecycle.md
similarity index 53%
rename from doc/HACKING/EndOfLifeTor.md
rename to doc/HACKING/ReleaseSeriesLifecycle.md
index 2fece2ca9..26770162f 100644
--- a/doc/HACKING/EndOfLifeTor.md
+++ b/doc/HACKING/ReleaseSeriesLifecycle.md
@@ -1,10 +1,11 @@
+
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 entire series that
-have reached their planned EOL: they do not apply to security-related
+has reached its planned EOL: they do not apply to security-related
deprecations of individual versions.
### 0. Preliminaries
@@ -24,6 +25,7 @@ deprecations of individual versions.
- tor's Travis CI cron jobs
- chutney's Travis CI tests (#)
- stem's Travis CI tests (#)
+ - tor's scripts/git/* scripts
2. Close the milestone in Trac. To do this, go to Trac, log in,
select "Admin" near the top of the screen, then select "Milestones" from
@@ -48,3 +50,49 @@ deprecations of individual versions.
number from their approved versions list.
7. Update the CoreTorReleases wiki page.
+
+8. Update the git/hooks
+
+9. Finally, make sure this document is up to date with our latest
+ process.
+
+10. Open a ticket (if there is not one already) for authorities to
+ start rejecting relays that are running that release series.
+ This ticket should be targeted for at least a month or two
+ after the series is officially EOL, unless there is an important
+ reason to un-list relays early.
+
+11. Open a ticket (if appropriate) for updates to the set of
+ required and recommended subprotocol versions.
+
+Starting a new release series.
+------------------------------
+
+(Ideally, do this immediately after a release.)
+
+1. Start a new maint-x.y.z branch based on master, and a new
+ release-x.y.z branch based on master. They should have the same
+ starting point.
+
+ Push both of these branches to the master git repository.
+
+2. In master, change the version to "0.x.y.0-alpha-dev". Run the
+ update_versions.py script, and commit this version bump.
+
+3. Tag the version bump with "tor-0.x.y.0-alpha-dev". Push the tag
+ and master.
+
+4. Open tickets for connecting the new branches to various other
+ places, including:
+
+ - Jenkins CI
+ - travis cronjobs
+ - chutney travis configuration
+ - Tor's scripts/git scripts.
+
+5. Remove "check-best-practices" from the check-local Makefile
+ target in maint-x.y.z branch only. Merge to release-0.xy.z but do
+ not forward-port to master.
+
+6. Finally, make sure this document is up to date with our latest
+ process.