Release Checklist » History » Version 71
Peter Amstutz, 05/20/2024 01:53 PM
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 | 20 | Peter Amstutz | Meta-process: |
13 | |||
14 | 22 | Peter Amstutz | # Periodically review this documented process reflects our actual process & update it |
15 | 70 | Brett Smith | # When steps are added/changed/rearranged/removed, be sure to update "@cmd/art/TASKS@ in the @arvados-dev@ repository":https://dev.arvados.org/projects/arvados/repository/arvados-dev/revisions/main/show/cmd/art. |
16 | 20 | Peter Amstutz | |
17 | 3 | Peter Amstutz | |_.Step|_.Who|_.What| |
18 | 70 | Brett Smith | |0|engineering|Build new features, refine good code into great code| |
19 | |1|engineering|Prepare release branch on the @arvados@ and @arvados-formula@ repositories. For major releases, this means branching a new @X.Y-staging@ from main. For minor releases, this means cherry-picking features onto the existing @X.Y-staging@ branch. Ensure that Redmine issues for features or bugfixes that are appearing for the first time in this version are associated with the correct release (for major releases, use @art redmine issues find-and-associate@).| |
||
20 | 1 | Peter Amstutz | |2|release eng|Update the "Upgrading Arvados and Release notes" doc page on @X.Y-staging@ branch with the version and date of the release. |
21 | On the @X.Y-staging@ branch, update these files to refer to the release version instead of @main@: |
||
22 | 70 | Brett Smith | * In @arvados/tools/arvbox/bin/arvbox@, update @DEFAULT_TAG=X.Y.Z@ |
23 | * In @arvados/sdk/R/DESCRIPTION@, update @Version:@| |
||
24 | |3|engineering|Ensure that the release staging branch passes automated tests on Jenkins. |
||
25 | For major releases, this means: |
||
26 | * "developer-run-tests":https://ci.arvados.org/job/developer-run-tests/ |
||
27 | * "developer-run-tests-doc-sdk-java-R":https://ci.arvados.org/job/developer-run-tests-doc-sdk-java-R/ |
||
28 | For minor releases, this means: |
||
29 | * X.Y-developer-run-tests |
||
30 | * X.Y-developer-run-tests-doc-sdk-java-R| |
||
31 | |4|engineering|Review release branch to make sure all commits that need to be in the release are in the release. If new commits are added, resume checklist from step 3.| |
||
32 | 44 | Peter Amstutz | |5|product mgr|Write release notes and publish them to www-dev site: https://www-dev.arvados.org/releases/| |
33 | 42 | Peter Amstutz | |6|everyone|Review release notes| |
34 | 70 | Brett Smith | |7|product mgr|Create a Redmine release for the next patch release after the current one.| |
35 | |8|release eng|Build release candidate packages with version "X.Y.Z~rcN-1" using the Jenkins job "build-and-publish-rc-packages":https://ci.arvados.org/job/build-and-publish-rc-packages/. Add a comment on the release ticket identifying the Git commit hash used for the build, and link to your Jenkins run.| |
||
36 | |9|release eng|Publish release candidate @arvados/jobs@ Docker image using "docker-jobs-image-release":https://ci.arvados.org/job/docker-jobs-image-release/| |
||
37 | 57 | Peter Amstutz | |10|ops|Test installer formula / provision scripts with RC packages - [[Installer development process]] ^1^| |
38 | 70 | Brett Smith | |11|ops|"Build a new compute image":https://ci.arvados.org/job/packer-build-compute-image/ and update Playground using the new RC packages and compute node image ^1^| |
39 | 71 | Peter Amstutz | |12|bfx|Run "CWL conformance tests":https://ci.arvados.org/view/CWL/job/arvados-cwl-conformance-tests/ on jenkins and "bam-to-vcf pipeline":https://workbench.pirca.arvadosapi.com/workflows/pirca-7fd4e-ut5n6r2ydl6o6kj on Playground ^1^| |
40 | 70 | Brett Smith | |13|engineering|Perform final manual testing based on risk assessment, the release notes and "manual testing plan":https://dev.arvados.org/projects/arvados/wiki/Manual_testing_plan.| |
41 | 69 | Peter Amstutz | |14|product mgr|Approve RC for release| |
42 | 70 | Brett Smith | |15|release eng|Build final release packages with version "X.Y.Z-1" using the Jenkins job "build-and-publish-rc-packages":https://ci.arvados.org/job/build-and-publish-rc-packages/. Add a comment on the release ticket identifying the Git commit hash used for the build, and link to your Jenkins run.| |
43 | |16|release eng|Publish stable release @arvados/jobs@ Docker image using "docker-jobs-image-release":https://ci.arvados.org/job/docker-jobs-image-release/| |
||
44 | |17|release eng|Push packages to stable repos using "publish-packages-to-stable-repo":https://ci.arvados.org/job/publish-packages-to-stable-repo/ (see also https://dev.arvados.org/projects/ops/wiki/Promoting_Packages_to_Stable)| |
||
45 | |18|release eng|Publish Python packages and Ruby gems using "build-publish-packages-python-ruby":https://ci.arvados.org/job/build-publish-packages-python-ruby/| |
||
46 | |19|release eng|Publish Java package using "build-java-sdk":https://ci.arvados.org/job/build-java-sdk/ and following [[Releasing Java SDK packages]]| |
||
47 | |20|release eng|Publish R package using "build-package-r":https://ci.arvados.org/job/build-package-r/| |
||
48 | |21|release eng|Publish @arvados/arvbox-demo@ Docker image using "build-and-release-arvbox-demo-image":https://ci.arvados.org/job/build-and-release-docker-arvbox-demo-image/| |
||
49 | |22|release eng|Tag the commits in each repo used to build the release in Git. Create an annotated tag (@git tag --annotate@) with a message like "Release X.Y.Z, release notes at https://arvados.org/release-notes/X.Y.Z/" That makes the "GitHub releases page":https://github.com/arvados/arvados/releases look good. See "GitHub documentation for more details about how to automate releases":https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes. |
||
50 | 1 | Peter Amstutz | Create or fast forward the @X.Y-release@ branch to match @X.Y-staging@. |
51 | 70 | Brett Smith | Cherry-pick the upgrade notes commit (from step 2) onto @main@.| |
52 | |23|release eng|Ensure new release is published on https://doc.arvados.org/. |
||
53 | Ensure that release notes & any other materials are pointing to correct version of the docs.| |
||
54 | 1 | Peter Amstutz | |24|ops|Update pirca and jutro to stable release| |
55 | 70 | Brett Smith | |25|product mgr|Merge release notes (step 6) from "develop" branch to "main" branch of the @arvados-www@ Git repository and check that the https://arvados.org front page is updated| |
56 | |26|product mgr|Send out the release notes via MailChimp, tweet from the Arvados account, announce on the Discourse forum, Matrix, etc.| |
||
57 | |27|release eng|For major releases: Duplicate the Jenkins configuration for the "run-tests" jobs tests to versioned names (run-tests-X.Y) so that future point releases remain testable after @main@ moves on. Note: if a Jenkins job isn't runnable after being copied (there no run button, or the multijob prints NullPointerException trying to run it), try disabling and re-enabling it.| |
||
58 | 1 | Peter Amstutz | |28|release eng|Add the release to "doi:10.5281/zenodo.6382942":https://doi.org/10.5281/zenodo.6382942 |
59 | [[Updating Zenodo Version of Arvados after Release]] |
||
60 | https://zenodo.org/record/6382943| |