Start from a clean checkout at master
.
Before running through the release it's good to run the build and the tests locally, and make sure CI is passing. You can also test-drive the commit in an existing Bazel workspace to sanity check functionality.
rules_python is currently using Zero-based versioning and thus backwards-incompatible API changes still come under the minor-version digit. So releases with API changes and new features bump the minor, and those with only bug fixes and other minor changes bump the patch digit.
- Update
version.bzl
with the new semantic versionX.Y.Z
. - Run
bazel build //distro:rules_python-X.Y.Z
to build the distributed tarball. - Calculate the Sha256 hash of the tarball. This hash will be used in the
http_archive
rules that download the new release.- Example command for OSX:
shasum --algorithm 256 bazel-bin/distro/rules_python-0.1.0.tar.gz
- Example command for OSX:
- Update nested examples in
examples/*/WORKSPACE
to get the new semantic version with the newsha256
hash. - Create commit called "Release X.Y.Z"
- "release 0.1.0" is an example commit.
- Tag that commit as
X.Y.Z
. Eg.git tag X.Y.Z
- Push the commit and the new tag to
master
. - Run
bazel build //distro:relnotes
from within workspace and then from repo root runcat bazel-bin/distro/relnotes.txt
to get the 'install instructions' that are added as release notes.- Check the
sha256
value matches the one you calculated earlier.
- Check the
- "Draft a new release" in Github (manual for now), selecting the recently pushed
X.Y.Z
tag. Upload the release artifact fromrules_python-[version].tar.gz
. Also copy therelnotes.txt
from step 8, adding anything extra if desired.
- Update
README.md
to point at new release. - Ping @philwo to get the new release added to mirror.bazel.build. See this comment on issue #400 for more context.
- Announce the release in the #python channel in the Bazel slack (bazelbuild.slack.com).