How to cut a Rubicon-ObjC release¶
The release infrastructure for Rubicon is semi-automated, using GitHub Actions to formally publish releases.
This guide assumes that you have an
upstream remote configured on your
local clone of the Rubicon repository, pointing at the official repository. If
all you have is a checkout of a personal fork of the Rubicon-ObjC repository,
you can configure that checkout by running:
$ git remote add upstream https://github.com/beeware/rubicon-objc.git
The procedure for cutting a new release is as follows:
Check the contents of the upstream repository’s main branch:
$ git fetch upstream $ git checkout --detach upstream/main
Check that the HEAD of release now matches upstream/main.
Make sure the branch is ready for release. Ensure that:
The version number has been bumped.
The release notes are up to date. If they are, the changes directory should be empty, except for the
These two changes (the version bump and release notes update) should go through the normal pull request and review process. They should generally comprise the last PR merged before the release occurs.
If the version number hasn’t been updated, or
changesdirectory isn’t empty, you need to create a PR (using the normal development process) that contains these changes. Run:
$ tox -e towncrier -- --draft
to review the release notes that will be included, and then:
$ tox -e towncrier
to generate the updated release notes. Submit the PR; once it’s been reviewed and merged, you can restart the release process from step 1.
Tag the release, and push the tag upstream:
$ git tag v1.2.3 $ git push upstream v1.2.3
Edit the GitHub release. Add release notes (you can use the text generated by towncrier). Check the pre-release checkbox (if necessary).
Double check everything, then click Publish. This will trigger a publication workflow on GitHub.
7. Wait for the package to appear on PyPI.
Congratulations, you’ve just published a release!
If anything went wrong during steps 3 or 5, you will need to delete the draft release from GitHub, and push an updated tag. Once the release has successfully appeared on PyPI, it cannot be changed; if you spot a problem in a published package, you’ll need to tag a completely new release.