Skip to content

Conversation

thundergolfer
Copy link

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:

  • Does not include precompiled binaries, eg. .par files. See CONTRIBUTING.md for info
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature (please, look at the "Scope of the project" section in the README.md file)
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

Does this PR introduce a breaking change?

  • Yes
  • No

Copy link
Contributor

@hrfuller hrfuller left a 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`
Copy link
Contributor

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?

Copy link
Author

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.

Copy link
Contributor

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

@thundergolfer
Copy link
Author

I think I'm missing a step about running ./update_docs.sh

Copy link
Contributor

@alexeagle alexeagle left a 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`
Copy link
Contributor

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

@thundergolfer thundergolfer merged commit 1696593 into master Mar 30, 2021
@thundergolfer thundergolfer deleted the jonathon--add-DEVELOPING-dot-md-mar2021 branch March 30, 2021 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants