Project

General

Profile

Actions
History

Wiki »

Release Checklist » History » Revision 72

« Previous | Revision 72/74 (diff) | Next »
Peter Amstutz, 05/20/2024 01:53 PM

Release Checklist

Pre-process:

  1. Create an issue for the release.
  2. Add each of the following steps (starting at step 1) as tasks with the step number in the subject
  3. Assign each task
  4. The current task goes into the "In Progress" column
  5. When the current task is finished, move it to resolved, and move the next task into "In Progress"
  6. Notify the assignee of the next task that it is ready to begin

Meta-process:

  1. Periodically review this documented process reflects our actual process & update it
  2. When steps are added/changed/rearranged/removed, be sure to update cmd/art/TASKS in the arvados-dev repository.
Step Who What
0 engineering Build new features, refine good code into great code
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).
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.
On the X.Y-staging branch, update these files to refer to the release version instead of main:
* In arvados/tools/arvbox/bin/arvbox, update DEFAULT_TAG=X.Y.Z
* In arvados/sdk/R/DESCRIPTION, update Version:
3 engineering Ensure that the release staging branch passes automated tests on Jenkins.
For major releases, this means:
* developer-run-tests
* developer-run-tests-doc-sdk-java-R
For minor releases, this means:
* X.Y-developer-run-tests
* X.Y-developer-run-tests-doc-sdk-java-R
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.
5 product mgr Write release notes and publish them to www-dev site: https://www-dev.arvados.org/releases/
6 everyone Review release notes
7 product mgr Create a Redmine release for the next patch release after the current one.
8 release eng Build release candidate packages with version "X.Y.Z~rcN-1" using the Jenkins 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.
9 release eng Publish release candidate arvados/jobs Docker image using docker-jobs-image-release
10 ops Test installer formula / provision scripts with RC packages - Installer development process
11 ops Build a new compute image and update Playground using the new RC packages and compute node image 1
12 bfx Run CWL conformance tests on jenkins and bam-to-vcf pipeline on Playground
13 engineering Perform final manual testing based on risk assessment, the release notes and manual testing plan.
14 product mgr Approve RC for release
15 release eng Build final release packages with version "X.Y.Z-1" using the Jenkins 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.
16 release eng Publish stable release arvados/jobs Docker image using docker-jobs-image-release
17 release eng Push packages to stable repos using publish-packages-to-stable-repo (see also https://dev.arvados.org/projects/ops/wiki/Promoting_Packages_to_Stable)
18 release eng Publish Python packages and Ruby gems using build-publish-packages-python-ruby
19 release eng Publish Java package using build-java-sdk and following Releasing Java SDK packages
20 release eng Publish R package using build-package-r
21 release eng Publish arvados/arvbox-demo Docker image using build-and-release-arvbox-demo-image
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 look good. See GitHub documentation for more details about how to automate releases.
Create or fast forward the X.Y-release branch to match X.Y-staging.
Cherry-pick the upgrade notes commit (from step 2) onto main.
23 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.
24 ops Update pirca and jutro to stable release
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
26 product mgr Send out the release notes via MailChimp, tweet from the Arvados account, announce on the Discourse forum, Matrix, etc.
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.
28 release eng Add the release to doi:10.5281/zenodo.6382942
Updating Zenodo Version of Arvados after Release
https://zenodo.org/record/6382943

Updated by Peter Amstutz 6 months ago · 72 revisions