mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
Merge branch 'ticket28453_v2' into ticket28453_v2_merged
This commit is contained in:
commit
4313f1cce8
50
doc/HACKING/EndOfLifeTor.md
Normal file
50
doc/HACKING/EndOfLifeTor.md
Normal file
@ -0,0 +1,50 @@
|
||||
|
||||
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.
|
@ -247,9 +247,11 @@ new Tor release:
|
||||
`maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours`
|
||||
merge to avoid taking that change into master.
|
||||
|
||||
2. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the
|
||||
2. If there is a new `maint-x.y.z` branch, create a Travis CI cron job that
|
||||
builds the release every week. (It's ok to skip the weekly build if the
|
||||
branch was updated in the last 24 hours.)
|
||||
|
||||
3. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the
|
||||
master branch.
|
||||
|
||||
3. Keep an eye on the blog post, to moderate comments and answer questions.
|
||||
|
||||
|
||||
4. Keep an eye on the blog post, to moderate comments and answer questions.
|
||||
|
Loading…
Reference in New Issue
Block a user