nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 22:03:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'tor-github/pr/1739'

Browse Source 
Ignored conflicting style changes: they will be re-applied in
the next commit.
This commit is contained in:
teor 2020-04-03 21:59:19 +10:00
commit 0efcdb8918
No known key found for this signature in database
GPG Key ID: 10FEAA0E7075672A
2 changed files with 101 additions and 48 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
doc/HACKING/EndOfLifeTor.md
View File

@ -1,48 +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.

101
doc/HACKING/ReleaseSeriesLifecycle.md Normal file
View File

@ -0,0 +1,101 @@
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.
### 1. Preliminaries
1. A few months before End of Life:
Write a deprecation announcement.
Send the announcement out with every new release announcement.
2. A month before End of Life:
Send the announcement to tor-announce, tor-talk, tor-relays, and the
packagers.
### 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
- 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
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. 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.
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.)
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.)
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. 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.x.y.z but do
not forward-port to master.
6. Finally, make sure this document is up to date with our latest
process.