From 455ea05bdfb841bfb84acdf464f497996824cd7a Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 14 Feb 2020 08:47:17 -0500 Subject: Rename EndOfLifeTor to ReleaseSeriesLifecycle; expand it. Closes ticket 30917. --- doc/HACKING/EndOfLifeTor.md | 50 ------------------ doc/HACKING/ReleaseSeriesLifecycle.md | 98 +++++++++++++++++++++++++++++++++++ 2 files changed, 98 insertions(+), 50 deletions(-) delete mode 100644 doc/HACKING/EndOfLifeTor.md create mode 100644 doc/HACKING/ReleaseSeriesLifecycle.md (limited to 'doc') diff --git a/doc/HACKING/EndOfLifeTor.md b/doc/HACKING/EndOfLifeTor.md deleted file mode 100644 index 2fece2ca9d..0000000000 --- a/doc/HACKING/EndOfLifeTor.md +++ /dev/null @@ -1,50 +0,0 @@ - -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 -deprecations of individual versions. - -### 0. Preliminaries - -0. A few months before End of Life: - Write a deprecation announcement. - Send the announcement out with every new release announcement. - -1. A month before End of Life: - Send the announcement to tor-announce, tor-talk, tor-relays, and the - packagers. - -### 1. On the day - -1. Open tickets to remove the release from: - - the jenkins builds - - tor's Travis CI cron jobs - - chutney's Travis CI tests (#) - - stem's Travis CI tests (#) - -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 - the menu on the left. Click on the milestone for this version, and - select the "Completed" checkbox. By convention, we select the date as - the End of Life date. - -3. Replace NNN-backport with NNN-unreached-backport in all open trac tickets. - -4. If there are any remaining tickets in the milestone: - - merge_ready tickets are for backports: - - if there are no supported releases for the backport, close the ticket - - if there is an earlier (LTS) release for the backport, move the ticket - to that release - - other tickets should be closed (if we won't fix them) or moved to a - supported release (if we will fix them) - -5. Mail the end of life announcement to tor-announce, the packagers list, - and tor-relays. The current list of packagers is in ReleasingTor.md. - -6. Ask at least two of weasel/arma/Sebastian to remove the old version - number from their approved versions list. - -7. Update the CoreTorReleases wiki page. diff --git a/doc/HACKING/ReleaseSeriesLifecycle.md b/doc/HACKING/ReleaseSeriesLifecycle.md new file mode 100644 index 0000000000..26770162f7 --- /dev/null +++ b/doc/HACKING/ReleaseSeriesLifecycle.md @@ -0,0 +1,98 @@ + + +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 +has reached its planned EOL: they do not apply to security-related +deprecations of individual versions. + +### 0. Preliminaries + +0. A few months before End of Life: + Write a deprecation announcement. + Send the announcement out with every new release announcement. + +1. A month before End of Life: + Send the announcement to tor-announce, tor-talk, tor-relays, and the + packagers. + +### 1. On the day + +1. Open tickets to remove the release from: + - the jenkins builds + - 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 + the menu on the left. Click on the milestone for this version, and + select the "Completed" checkbox. By convention, we select the date as + the End of Life date. + +3. Replace NNN-backport with NNN-unreached-backport in all open trac tickets. + +4. If there are any remaining tickets in the milestone: + - merge_ready tickets are for backports: + - if there are no supported releases for the backport, close the ticket + - if there is an earlier (LTS) release for the backport, move the ticket + to that release + - other tickets should be closed (if we won't fix them) or moved to a + supported release (if we will fix them) + +5. Mail the end of life announcement to tor-announce, the packagers list, + and tor-relays. The current list of packagers is in ReleasingTor.md. + +6. Ask at least two of weasel/arma/Sebastian to remove the old version + 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. -- cgit v1.2.3-54-g00ecf From b1a571f0387aa07f11e79147209a8c74c9937a04 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 23 Mar 2020 09:27:16 -0400 Subject: Edits requested by teor --- doc/HACKING/ReleaseSeriesLifecycle.md | 55 ++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 26 deletions(-) (limited to 'doc') diff --git a/doc/HACKING/ReleaseSeriesLifecycle.md b/doc/HACKING/ReleaseSeriesLifecycle.md index 26770162f7..d0ce173336 100644 --- a/doc/HACKING/ReleaseSeriesLifecycle.md +++ b/doc/HACKING/ReleaseSeriesLifecycle.md @@ -4,28 +4,30 @@ 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 -has reached its planned EOL: they do not apply to security-related +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. -### 0. Preliminaries +### 1. Preliminaries -0. A few months before End of Life: +1. A few months before End of Life: Write a deprecation announcement. Send the announcement out with every new release announcement. -1. A month before End of Life: +2. A month before End of Life: Send the announcement to tor-announce, tor-talk, tor-relays, and the packagers. -### 1. On the day +### 2. On the day 1. Open tickets to remove the release from: - the jenkins builds - tor's Travis CI cron jobs - - chutney's Travis CI tests (#) - - stem's Travis CI tests (#) - - tor's scripts/git/* scripts + - chutney's Travis CI tests + - sbws' Travis CI tests + - stem's Travis CI tests (but see + https://github.com/torproject/stem/issues/51) + - tor's scripts/git/gist-list-tor-branches.sh script 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 @@ -51,22 +53,28 @@ deprecations of individual versions. 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 +8. 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. +9. (LTS end-of-life only) Open a ticket (if appropriate) for updates to the + set of required and recommended subprotocol versions. (For the process + here, see proposal 303.) -Starting a new release series. ------------------------------- +10. (LTS end-of-life only) Open a ticket to remove no-longer-needed + consensus methods. (For the process here, see proposal 290.) + +11. (All EOL) Open a ticket to grep for obsolete series names (e.g., "0.2.9" + and "029") in tor, chutney, sbws, fallback-scripts, and so on. These + should be updated or removed. + +12. Finally, make sure this document is up to date with our latest + process. + + +### 3. Starting a new release series. (Ideally, do this immediately after a release.) @@ -83,15 +91,10 @@ Starting a new release series. 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. + places. See section 2 above for a list of affected locations. 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 + target in maint-x.y.z branch only. Merge to release-0.x.y.z but do not forward-port to master. 6. Finally, make sure this document is up to date with our latest -- cgit v1.2.3-54-g00ecf