The Wayback Machine - https://web.archive.org/web/20210104141706/https://github.com/bazelbuild/rules_python/issues/317
Skip to content

/ rules_python

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

Jump to bottom

Documenting release process #317

Open
thundergolfer opened this issue May 23, 2020 · 3 comments
Open

Documenting release process #317

thundergolfer opened this issue May 23, 2020 · 3 comments

Comments

@thundergolfer
Copy link
Collaborator

@thundergolfer thundergolfer commented May 23, 2020 •
edited

This is a tracking issue to gather information and settle on the contents of a RELEASE.md file to document how rules_python gets released. When doing it for the first time, I admittedly got a little lost, and it would be better to have this information out in the open as much as possible.

Below is my current understanding of how releasing should be done, updating as I learn new things or am corrected by the Google co-maintainers.

The release process

  1. Update version.bzl with the new semantic version
  2. Theres's a distro/BUILD file that uses bazelbuild/rules_pkg to create the tarball that's uploaded to Github. This comment suggests this step is run on CI somewhere?
  3. Run bazel build //distro:relnotes from within workspace and then from repo root run cat bazel-bin/distro/relnotes.txt to get the 'install instructions' that are added as release notes.
  4. Nested examples/*/WORKSPACE files need to get version-bumped on releases too.
@thundergolfer
Copy link
Collaborator Author

@thundergolfer thundergolfer commented Jun 14, 2020

This comment suggests this step is run on CI somewhere?

@brandjon do maintainers need to interact with a CI system as part of releasing this project?
@thundergolfer
Copy link
Collaborator Author

@thundergolfer thundergolfer commented Jul 21, 2020

Think I'll go ahead and document a release process that doesn't involve interaction with the CI system beyond getting a green build on the released commit.
@thundergolfer thundergolfer mentioned this issue Aug 31, 2020
Merged
@alexeagle
Copy link
Collaborator

@alexeagle alexeagle commented Aug 31, 2020

Happy to contribute to this, we've got a pretty refined release process for rules_nodejs that includes auto-bumping the documentation.
One thing to include here is the nested examples/*/WORKSPACE files need to get version-bumped on releases too.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
@alexeagle @thundergolfer
You can’t perform that action at this time.