commit 455ea05bdfb841bfb84acdf464f497996824cd7a Author: Nick Mathewson nickm@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.