-
Notifications
You must be signed in to change notification settings - Fork 21
Release Process
These steps describe how to make a release. This guide assumes that you have cloned roman_datamodels
, and added a remote named upstream
pointing to the central repository:
git remote add upstream https://github.com/spacetelescope/roman_datamodels.git
These steps should be undertaken on the main
branch:
-
Run
towncrier build
with the desired release version, to build the next changelog entry inCHANGES.rst
from fragments in thechanges/
directory:pip install towncrier towncrier build --version 0.17.0
-
Update
pyproject.toml
to pin therad
dependency above the newest release that has API-breaking changes (i.e. the newest minor release):[project] dependencies = [ "rad >= 0.17.0", ]
Caution
PyPI will reject any submission with Git dependencies in its metadata (i.e. git+https://github.com/spacetelescope/rad.git@main
). Dependencies must be defined against a released version available on PyPI (i.e. rad>=0.17.0
).
- Commit your changes and push to
main
onspacetelescope/roman_datamodels
.
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
:git fetch --all --tags git checkout -t upstream/main
-
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 branchrelease/1.8.x
.
git checkout -b release/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/release/a.b.x
):git checkout release/a.b.x git pull
-
Cherry-pick relevant commits from
main
that should be included in the patch release (including the new change log 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 main
branch in the Actions
tab:
https://github.com/spacetelescope/roman_datamodels/actions/workflows/ci.yml?query=branch%3Amain
Once the release branch is situated, it's a good idea to confirm that our release candidate doesn't break the following test suites:
-
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/roman_datamodels.git@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 "a.b.c on release/a.b.x"
-
Push the new tag to the upstream remote:
git push upstream a.b.c
The stable
branch points to the latest official release of roman_datamodels
. 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
-
Visit the
spacetelescope/roman_datamodels
repository's releases page. -
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
). -
Publish
the release.
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/roman_datamodels/#history
Additionally, you can test installing the new version with pip
:
pip install roman_datamodels==a.b.c
-
Make sure
CHANGES.rst
has a section for the next release. -
Tag
main
/master
for further development (if necessary)If the release branch has diverged from
main
/master
, you will need to tag theHEAD
ofmain
/master
with a development tag. This allows thesetuptools-scm
plugin to show the correct version for a locally installation. For example, if we just released version1.2.1
, the development tag would be1.2.2.dev
.git fetch upstream git checkout upstream/master git tag -a a.b.d.dev -m "development tag after divergence" git push upstream a.b.d.dev