Project

General

Profile

Release Checklist » History » Version 18

Lucas Di Pentima, 09/21/2021 07:48 PM
Salt doc pages doesn't need release version updates anymore.

1 1 Peter Amstutz
h1. Release Checklist
2
3
Pre-process:
4
5
# Create an issue for the release.
6
# Add each of the following steps (starting at step 1) as tasks with the step number in the subject
7
# Assign each task
8
# The current task goes into the "In Progress" column
9
# When the current task is finished, move it to resolved, and move the next task into "In Progress"
10
# Notify the assignee of the next task that it is ready to begin
11
12 3 Peter Amstutz
|_.Step|_.Who|_.What|
13
|0|engineering|Write lots of great code, build new features|
14 15 Ward Vandewege
|1|engineering|Go through https://dev.arvados.org/projects/arvados/wiki/Manual_testing_plan|
15 16 Peter Amstutz
|2|engineering|Prepare release branch ready for release candidate.
16
Update these files to use the release branch or version instead of main: 
17
@tools/salt-install/provision.sh@
18 18 Lucas Di Pentima
@tools/arvbox/bin/arvbox@|
19 15 Ward Vandewege
|3|engineering|Review release branch, make sure all commits that need to be in the release are in the release, make sure that dependencies of Python and Ruby packages have upper version pins (to ensure that 3rd party dependencies updated post-stable-release don't break our code)|
20
|4|product mgr|Create a redmine release for the next patch release beyond this one so that future bugfixes can be assigned to it, if there's a chance that such a release will be made.|
21
|5|engineering|Record git commits that will be used to build the release following the instructions at https://dev.arvados.org/projects/ops/wiki/Arvados_Release_lifecycle#Cut-off-commits-Choosing-a-Version|
22
|6|release eng|Build release candidate packages|
23
|7|product mgr|Send out draft release notes|
24
|8|everyone|Review release notes|
25
|9|ops|Test installer formula / provision scripts with RC packages - [[Installer development process]]|
26
|10|ops|Deploy RC packages to playground ^1^|
27
|11|bfx|Run "bam-to-vcf pipeline":https://dev.arvados.org/issues/17049#note-7 on playground ^1^|
28 17 Peter Amstutz
|12|product mgr|Sign off on last built RC as the release|
29
|13|release eng|Push packages to stable repos (https://dev.arvados.org/projects/ops/wiki/Promoting_Packages_to_Stable)|
30
|14|release eng|Publish arvados/jobs docker image, Python packages and Ruby gems|
31
|15|release eng|Publish formula / installer for the release|
32
|16|release eng|Publish arvados/arvbox-demo docker image with https://ci.arvados.org/view/Release%20Pipeline/job/build-and-release-arvbox-image/|
33
|17|release eng|Tag the commits in each repo used to build the release in git. Please create an annotated tag, with this message: "Release X.Y.Z, release notes at https://arvados.org/release-notes/X.Y.Z/". That will make https://github.com/arvados/arvados/releases look really good.|
34
|18|release eng|(major releases only, unless there is a change worthy in the point release) Update the "Upgrading Arvados and Release notes" doc page with the title and date of the release|
35
|19|release eng|Ensure new release is published on https://doc.arvados.org ; ensure that release notes & any other materials are pointing to correct version of the docs.|
36
|20|product mgr|Add release notes to https://arvados.org/release-notes/X.Y.Z.html and Update release list at https://arvados.org|
37
|21|product mgr|Send release notes to arvados and arvados-dev mailing list, tweet from the Arvados account about the new release, announce on gitter, notify customers, etc|
38
|22|release eng|Duplicate the jenkins configuration for tests to versioned names so that future point releases remain testable after master moves on|
39 1 Peter Amstutz
40
^1^ If issues are discovered in these steps, get a fix developed, reviewed and merged, and then update the ops ticket from step 3 with the relevant new git commit(s), notify ops, and resume the checklist from step 4.