-
-
Notifications
You must be signed in to change notification settings - Fork 632
Add DEVELOPING.md to document release. #428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add DEVELOPING.md to document release. #428
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall improvement. Thanks.
1. Update `version.bzl` with the new semantic version `X.Y.Z`. | ||
2. Run `bazel build //distro:rules_python-X.Y.Z` to build the distributed tarball. | ||
3. Calculate the Sha256 hash of the tarball. This hash will be used in the `http_archive` rules that download the new release. | ||
1. Example command for OSX: `shasum --algorithm 256 bazel-bin/distro/rules_python-0.1.0.tar.gz` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slightly confusing that we generate a sha sum for the release and then embed it in the release commit. Shouldn't adding the new sha change the release sha?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it is confusing I agree. It doesn't change the sha256 because the sha256 is added into the examples/
directory which isn't included in the sha'd distributable. It a bit awkward to do it this way but it allows you to have one commit "release X.Y.Z" that contains the necessary version.bzl bump and also updates to the examples (and README possibly).
It could be more straightforward though to just do the examples/ update in a followup commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice --algorithm
instead of -a
I think I'm missing a step about running |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yay reproducibility :)
1. Update `version.bzl` with the new semantic version `X.Y.Z`. | ||
2. Run `bazel build //distro:rules_python-X.Y.Z` to build the distributed tarball. | ||
3. Calculate the Sha256 hash of the tarball. This hash will be used in the `http_archive` rules that download the new release. | ||
1. Example command for OSX: `shasum --algorithm 256 bazel-bin/distro/rules_python-0.1.0.tar.gz` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice --algorithm
instead of -a
Description
Introduces a DEVELOPING.md document alongside CONTRIBUTING.md, just like rules_nodejs does. The primary motivation for this addition is to document the release process better ahead of releasing
0.2.0
.For convenience, can 'View File' on the new document here: jonathon--add-DEVELOPING-dot-md-mar2021/DEVELOPING.md
PR Checklist
Please check if your PR fulfills the following requirements:
.par
files. See CONTRIBUTING.md for infoPR Type
What kind of change does this PR introduce?
Does this PR introduce a breaking change?