Release Checklist » History » Revision 28
- Create an issue for the release.
- Add each of the following steps (starting at step 1) as tasks with the step number in the subject
- Assign each task
- The current task goes into the "In Progress" column
- When the current task is finished, move it to resolved, and move the next task into "In Progress"
- Notify the assignee of the next task that it is ready to begin
- Periodically review this documented process reflects our actual process & update it
- When steps are added/changed/rearranged/removed, be use to update the TASKS file used by the Arvados release tool: https://dev.arvados.org/projects/arvados/repository/arvados-dev/revisions/main/show/cmd/art
|Write lots of great code, build new features
|Prepare release branch. For major releases this means branching a new
X.Y-dev from main. For minor releases, this means cherry-picking features onto the existing
X.Y-dev branch. Ensure that tickets are marked with the correct version number (for major releases, use
art redmine issues find-and-associate)
|Update the "Upgrading Arvados and Release notes" doc page on both
main and the
X.Y-dev release branch with the version and date of the release.
X.Y-dev branch, update these files to refer to the release version instead of
|Ensure that the release branch passes automated tests on jenkins.
|Go through https://dev.arvados.org/projects/arvados/wiki/Manual_testing_plan
|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)
|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.
|Write release notes and publish them to www-dev site: https://www-dev.arvados.org/releases/
|Review release notes
|Build release candidate packages with version "X.Y.Z~rcN-1" using the jenkins jobs build-and-publish-rc-packages and workbench2-build-release-candidate-package . Record the "arvados" and "arvados-workbench2" git commits that were used, as well as links to the jenkins runs on a comment on the release ticket.
|Test installer formula / provision scripts with RC packages - Installer development process 1
|Deploy RC packages to playground 1
|Run bam-to-vcf pipeline on playground 1
|Approve RC for release
|Build final release packages with version "X.Y.Z-1" using the jenkins jobs build-and-publish-rc-packages and workbench2-build-release-candidate-package . Record the "arvados" and "arvados-workbench2" git commits that were used, as well as links to the jenkins runs on a comment on the release ticket.
|Push packages to stable repos using publish-packages-to-stable-repo (see also https://dev.arvados.org/projects/ops/wiki/Promoting_Packages_to_Stable)
|Publish arvados/jobs docker image using docker-jobs-image-release , Python packages and Ruby gems using build-publish-packages-python-ruby
|? Publish formula / installer for the release
|Publish arvados/arvbox-demo docker image using build-and-release-arvbox-image
|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.
|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.
|Merge release notes (step 6) from "develop" branch to "main" branch of
arvados-www git repository and check that https://arvados.org page is updated
|Send out email notifications , tweet from the Arvados account, announce on the Discourse forum, gitter, etc
|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
1 If issues are discovered requiring additional commits, increase the release candidate version by one, and and resume the checklist from step 7.