-
Notifications
You must be signed in to change notification settings - Fork 32
Release Procedures
This guide assumes that you have cloned stcal
, and added a remote named upstream
pointing to the central repository:
git remote add upstream https://github.com/spacetelescope/stcal.git
These steps should be undertaken on the main
/ master
branch:
-
Edit the change log
CHANGES.rst
; in the entry corresponding to your intended release (a.b.c (unreleased)
), changeunreleased
to the current date inYYYY-MM-DD
format. Also add a new change log entry above, with the formata.b.d (unreleased)
. -
Commit your changes and push to
main
/master
onspacetelescope/stcal
.
If you're making a major or minor version release, then the release branch will not yet exist. If you're releasing a patch version, then a release branch will already exist. Select one of the next two sections accordingly.
- Fetch and checkout the upstream
main
/master
:
git fetch --all --tags
git checkout upstream/master
- Inspect the log to ensure that no commits have snuck in since your changelog updates:
git log
- Create a new release branch. The name of the release branch should share the major and minor version of your release version, but the patch version should be
x
. For example, when releasing1.8.0
, name the branch1.8.x
.
git checkout -b a.b.x
- Push the branch to the upstream remote:
git push -u upstream HEAD
- GitHub actions should notice the new branch and run the tests. Wait until the job completes before proceeding.
In the case of a patch release, the release branch will already exist.
- Checkout and freshen release branch (this assumes that your local branch is already tracking
upstream/a.b.x
):
git checkout a.b.x
git pull
- Cherry-pick relevant commits from
main
/master
that should be included in the patch release (including the new changelog commit):
git cherry-pick ...
- Push updates to the upstream remote:
git push upstream HEAD
The creation or update of the release branch should have triggered a CI job on GitHub actions. Find the latest build on the release branch in the Actions
tab:
https://github.com/spacetelescope/stcal/actions/workflows/ci.yml
Once the release branch is situated, it's a good idea to confirm that our release candidate doesn't break the following test suites:
-
jwst
regression tests (add a PEP508 string to thepip
dependencies input field that points to the release commit, e.g.git+https://github.com/spacetelescope/stcal.git@fbd97cc
) -
romancal
regression tests (add a PEP508 string to thepip
dependencies input field that points to the release commit, e.g.git+https://github.com/spacetelescope/stcal@fbd97cc
)
At this point, you should have the release branch checked out and ready to tag.
- Create an annotated tag with a name that matches your intended release:
git tag -a a.b.c -m "Tagging a.b.c release on a.b.x release branch"
- Push the new tag to the upstream remote:
git push upstream a.b.c
The stable
branch points to the latest official release of stcal
. If the current release has become the latest, then the next step is to rewrite the stable branch to point our new tag.
git checkout stable
git reset --hard a.b.c
git push upstream stable --force
-
Click Draft a new release.
-
Select the existing tag that you just created and pushed, and title the release the same as the tag (i.e.,
a.b.c
). -
Press the
Publish release
button.
Publishing the GitHub release should trigger an automated workflow that should build the wheel and source distribution and publish the package to PyPI.
After this workflow completes, you can confirm that the new release appears on PyPI: https://pypi.org/project/stcal/#history
Additionally, you can test installing the new version with pip
:
pip install stcal==a.b.c