Skip to content

RELEASING.md

Latest commit

 

History

History
160 lines (109 loc) · 6.14 KB

RELEASING.md

File metadata and controls

160 lines (109 loc) · 6.14 KB

Releasing

Releases of globus-compute-sdk and globus-compute-endpoint are always published in unison and with the same version number, even when only one package has changes.

The process is partially automated with tools to help along the way.

Prerequisites

You must have the following tools installed and available:

  • git
  • scriv
  • tox

You will also need the following credentials:

  • a configured GPG key in git in order to create signed tags
  • pypi credentials for use with twine (e.g. a token in ~/.pypirc) valid for publishing globus-compute-sdk and globus-compute-endpoint
  • Globus VPN access

⚠️ The Jenkins build pages need to be accessed via VPN.

Alpha releases

  1. Branch off from the main branch to create a release branch (e.g., v.1.1.0):

    $ git checkout -b v1.1.0 main

  2. Bump the version of both packages, and the endpoint's SDK dependency, to a new alpha release (e.g., 1.0.0 -> 1.1.0a0):

    $ $EDITOR compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py

  3. Commit the changes:

    $ git add compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py
$ git commit -m "Bump versions for alpha release v1.1.0a0"
$git push -u origin v1.1.0

  4. Run ./release.sh from the repo root. This script creates a signed tag named after the current version and pushes it to GitHub, then uses the tox release command to push each package to PyPi.

  5. Navigate to the Build with Parameters Jenkins page.

  6. Enter the name of the release branch (eg, v4.8.0) into the BRANCH_OR_TAG field. (Leave BUILD_FOR_STABLE unchecked.)

  7. Click the Build button.

  8. Wait 15-30 minutes and confirm that the build is green.

Alpha release bugfixes

  1. Branch off from the release branch to create a new bugfix branch:

    $ git checkout -b some-bugfix v1.1.0

  2. Commit your changes and push to GitHub.

    $ git add .
$ git commit -m "Fixed X"
$ git push -u origin some-bugfix

  3. Open a PR in GitHub to merge the bugfix branch into the release branch.

  4. Once the PR is approved and merged, pull the new commits from the remote release branch:

    $ git checkout v1.1.0
$ git pull

  5. Repeat steps 2 through 4 of the main Alpha releases procedure. Be sure to only bump the alpha version number (e.g., 1.1.0a0 -> 1.1.0a1).

Production releases

  1. Checkout the release branch.

    $ git checkout v1.1.0

  2. Remove the alpha version designation for both packages and the endpoint's SDK dependency (e.g., 1.1.0a1 -> 1.1.0):

    $ $EDITOR compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py

  3. Update the changelog:

    $ scriv collect --edit

  4. Commit the changes:

    $ git add changelog.d/ docs/changelog.rst
$ git add compute_sdk/globus_compute_sdk/version.py compute_endpoint/setup.py compute_endpoint/globus_compute_endpoint/version.py
$ git commit -m "Bump versions and changelog for release v1.1.0"
$ git push

  5. Run ./release.sh from the repo root.

  6. Open a PR in GitHub to merge the release branch into main.

    ⚠️ Important: Once approved, merge the PR using the "Merge commit" option. This will ensure that the tagged commits and bug fixes from the release branch are properly added to the main branch.

  7. Create a GitHub release from the tag. See GitHub documentation for instructions.

  8. Navigate to the Build with Parameters Jenkins page.

  9. Enter the name of the release branch (eg, v4.8.0) into the BRANCH_OR_TAG field, and ensure BUILD_FOR_STABLE is checked.

  10. Click the Build button.

  11. Wait 15-30 minutes and confirm that the build is green.

  12. Depending on whether GCS is also releasing:

DEB/RPM Packaging Notes

Our alpha builds will go to the unstable repo, and production packages goes to both the testing and stable repos.

After this build process for production, the testing and stable packages will reside in an internal globus 'holding' repo. GCS manages the infrastructure so we need to run another Jenkins build to push it to live if GCS is not doing a release the same week which also pushes our packages. See last pipeline step above.