OpsGuide Releases

Pre-Release

Guidelines for a release:

1. All issues in the unstable branch milestone are closed.
2. The unstable branch has been in active use by testers/the canary server for at least a month.
3. No new bug reports have been filed for at least 2 weeks.

Release Artifacts

Maven - Upstream

The standard JAR artifact distribution mechanic. We maintain a maven repository at https://maven.mimirdb.info to which everything is published. Prior to the release process for Vizier, jars need to be published for upstream repositories. (These should be published in-order, and artifact generation for both needs to be complete or there will be a build error)

1. UBOdin/mimir-caveats
2. UBOdin/mimir-api

Maven jars are versioned based on the version numbers in the build.sbt files of the respective repositories. During normal development, these should be at a -SNAPSHOT version (unless no changes have been made since the last Vizier release).

Maven - Vizier

The release procedure for the Vizier repository is:

1. Run python3 scripts/fix_copyrights.py (This ensures that all files have copyright tags)
2. Remove the -SNAPSHOT marker and commit the version branch. (Any specific version without a -SNAPSHOT marker should only ever have a single repository commit)
3. Approve the pull request to merge the version branch into master.
4. Locally pull the new master branch.
5. mill vizier.test
6. bash scripts/publish.sh (This can only be done once you've logged into Vizier's sonatype account)
7. Wait for the publish script to finish.
8. bash scripts/bootstrap.sh
9. Create a new release off of the master branch in GitHub, using the resulting bin/vizier binary. Don't forget to set the tag name.
10. Update the version branch to have a 0.0.1-SNAPSHOT version
11. python3 scripts/build_docker.py okennedy/vizier:vX.Y.Z (Update the tag name appropriately; Requires authority to push to the tag)
12. Close the active milestone and create a milestone and draft commit for the next 0.0.1 version.

(TODO: Automate these steps)

Bootstrap Launcher

Coursier provides a bootstrap script, a small file containing the Coursier resolver that will fetch Vizier and its dependencies and run them. The bootstrap file needs to be re-generated for each Vizier release. GitLab takes care of this automatically during the release process for vizier-scala.

Coursier Manifest

Coursier provides a way to install files based on a small manifest file located at https://vizierdb.info/coursier.json This file needs to be re-generated for each Vizier release. GitLab takes care of this automatically during the release process for vizier-scala.

Version Management Guidelines

Version Numbering Conventions

Version numbering conventions are as follows:

• Bump by 0.0.1: bugfix version (Bugfixes for a stable release; No new features)
• Bump by 0.1.0: minor version (New features; No API breaks)
• Bump by 1.0.0: major version (Something that could break an API/is not backwards compatible. Avoid if possible, and always provide a migration path for old data)

Milestone Categories

Version milestones on the bug tracker should fall into one of the following categories:

• Stable: This version has been tested extensively and is ready for production use. New tickets must be flagged Bug.
• Testing: Development on this version has been completed, but it may not be ready for production use. New tickets must be flagged Bug. At most one version should be in this state at a time.
• Development: This version is currently being developed. No new tickets unless flagged Bug or accompanied by a pull request. At most one version should be in this state at a time.
• Next: Development on this version has not yet started.

Other Notes

1. At most one significant internal change/rewrite/rengineering effort per minor version. Try to balance significant internal changes with low-hanging fruit features and bugfixes.