3.1   Get codekit installed¶

The release manager can folow the instructions at:

https://github.com/lsst-sqre/sqre-codekit

If you are working interactively you want to set the environment variable DM_SQUARE_DEBUG to 1 as it gives more insight on what is going on with the Github REST API calls.

3.2   Github teams¶

There are three “special” teams in the LSST Github org

These are:

• Data Management
• DM Externals
• DM Auxilliaries

These are used in the release process in the following way:

Data Management repos that are a dependency of lsst_distrib are tagged with the bare release version, eg. 14.0 DM Externals that are a dependency of lsst_distrib are tagged with v14.0 (so that eups does not show it and confuse people who want the upstream semantic versioning to show up) DM Auxilliaries are repos that we want to snapshot as part of a relase (eg sdss_demo) but are not an eups dependancy of lsst_distrib.

3.3   Release the demo¶

Go to https://github.com/lsst/lsst_dm_stack_demo/releases and ‘Draft a new release’ with your tag. See its release history for examples.

3.4   Branching the docs¶

At this point you should branch lsst/pipelines_lsst_io

git clone https://github.com/lsst/pipelines_lsst_io.git
git checkout -b 14.0

Update the demo.rst page to point to the demo release you just made and use this version for testing your candidates as described in the pipelines documentation for testing your installation.

4.1   Tag the candidate¶

Tagging first and third parties allows the release to be reproduceable in the future and is necessary for the final build process.

Note the difference in tag name convention between first and third parties.

# git tag the first parties

github-tag-version --org lsst --team 'Data Management' --candidate v14_0_rc2 14.0 bXXXX
github-tag-version --org lsst --team 'Database' --candidate v14_0_rc2 14.0 bXXXX

# for externals NOTE THE v PREFIX to avoid stomping on the eups semantic versioning
github-tag-version --org lsst --team 'DM Externals' --candidate v14_0_rc2 v14.0 bXXXX

This is the final tag against the third parties since they are slow-moving and have been proven to work with the weekly candidate seed. In the rare event where a problem is identified the tag can be moved along.

4.2   Publish the candidate¶

5.1   Branching lsst¶

In this process we make use of the fact that git doesn’t care whether a ref is a tag or a branch to constrain the number of branches to repositories that need retroactive maintainance or need to be available in more than one cadence. One such example is the lsst repo since it containes newinstall.sh which sets the version of eups, and that may be different for an official release than the current bleed.

The first repo that should be branched is lsst/lsst:

git clone https://github.com/lsst/lsst.git
git checkout -b 14.0

Now in lsst/scripts/newinstall.sh change the canonical reference for this newinstall to be one associated with the current branch:

NEWINSTALL="https://raw.githubusercontent.com/lsst/lsst/14.0/scripts/newinstall.sh"

and commit and push.

This means that if you need to update newinstall.sh for bleed users, official-release users will not be prompted to update to the latest version, but will phone home against their official-release branch for hotfixes.

Also double-check for other things that might need to be updated, like the documentation links (though these should really be fixed on master prior to branching or cherry-picked back).

5.2   Doc update: newinstall.rst¶

Update the newinstall.rst page on your release branch of pipelines_lsst_io with the new download location of the newinstall.sh script.

5.3   Final tag¶

Now it’s time to lay down the final git tag. For repositories that have already been branched with the 14.0 ref, that will fail, which is fine.

This is mostly a repeat of the process for laying down the candidate tag but this time we use numeric tags so that eups will see them:

# tag repos involved in the final candidate and final build
github-tag-version --org lsst --team 'Data Management' --candidate v14_0_rc2 14.0 b3176
github-tag-version --org lsst --team 'Database' --candidate v14_0_rc2 14.0 b3176

Since you already tagged the third parties with their special final tag already, no need to do anything here.

5.4   Release build¶

• Submit the run-rebuild job with your parameters (eg. 14.0 v14.0)
• At this point you should not be seeing master-g type references as eups versions. Everything should have a tag-derviced version such as 14.0 if they are a DM repo and their semantic tag (eg. pyfits 3.0) if they are external. If you see one, you need to chase down why. The only situation that should happen is if a third party but a branch is used for LSST development that lacks any other type of semantic versioning (in the 14.0 release this included starlink_ast and jointcal_cholmod.
• Note your final bNNNN number for the publish (either from the build log or by looking at the next of the annotated 14.0 tag on any repo eg. afw).
• Submit the run-publish job making sure you have selected package and not git as the option.

5.5   Other OS checking¶

While we only officially support the software on certain platforms (RHEL/CentOS 7 is the reference, and we CI MacOS and RHEL 6), we check in a number of other popular platforms (eg Ubuntu, newer versions of CentOS etc) by spinning up machines on Digital Ocean (typically) and following the user install instructions. This also allows us to check the user from-scratch installation instructions including the pre-requisites.