diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8928246c93..8805d458e8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -3,6 +3,21 @@
We'd love to accept your patches and contributions to this project. There are
just a few small guidelines you need to follow.
+## Contributor License Agreement
+
+First, the most important step: signing the Contributor License Agreement. We
+cannot look at any of your code unless one is signed.
+
+Contributions to this project must be accompanied by a Contributor License
+Agreement. You (or your employer) retain the copyright to your contribution,
+this simply gives us permission to use and redistribute your contributions as
+part of the project. Head over to to see
+your current agreements on file or to sign a new one.
+
+You generally only need to submit a CLA once, so if you've already submitted one
+(even if it was for a different project), you probably don't need to do it
+again.
+
## Getting started
Before we can work on the code, we need to get a copy of it and setup some
@@ -65,15 +80,6 @@ and setup. Subsequent runs will be faster, but there are many tests, and some of
them are slow. If you're working on a particular area of code, you can run just
the tests in those directories instead, which can speed up your edit-run cycle.
-## Updating tool dependencies
-
-It's suggested to routinely update the tool versions within our repo - some of the
-tools are using requirement files compiled by `uv` and others use other means. In order
-to have everything self-documented, we have a special target -
-`//private:requirements.update`, which uses `rules_multirun` to run in sequence all
-of the requirement updating scripts in one go. This can be done once per release as
-we prepare for releases.
-
## Formatting
Starlark files should be formatted by
@@ -99,18 +105,6 @@ $ buildifier --lint=fix --warnings=native-py -warnings=all WORKSPACE
Replace the argument "WORKSPACE" with the file that you are linting.
-## Contributor License Agreement
-
-Contributions to this project must be accompanied by a Contributor License
-Agreement. You (or your employer) retain the copyright to your contribution,
-this simply gives us permission to use and redistribute your contributions as
-part of the project. Head over to to see
-your current agreements on file or to sign a new one.
-
-You generally only need to submit a CLA once, so if you've already submitted one
-(even if it was for a different project), you probably don't need to do it
-again.
-
## Code reviews
All submissions, including submissions by project members, require review. We
@@ -198,31 +192,6 @@ merged:
`compile_pip_requirements` update target, which is usually in the same directory.
e.g. `bazel run //docs:requirements.update`
-## Core rules
-
-The bulk of this repo is owned and maintained by the Bazel Python community.
-However, since the core Python rules (`py_binary` and friends) are still
-bundled with Bazel itself, the Bazel team retains ownership of their stubs in
-this repository. This will be the case at least until the Python rules are
-fully migrated to Starlark code.
-
-Practically, this means that a Bazel team member should approve any PR
-concerning the core Python logic. This includes everything under the `python/`
-directory except for `pip.bzl` and `requirements.txt`.
-
-Issues should be triaged as follows:
-
-- Anything concerning the way Bazel implements the core Python rules should be
- filed under [bazelbuild/bazel](https://github.com/bazelbuild/bazel), using
- the label `team-Rules-python`.
-
-- If the issue specifically concerns the rules_python stubs, it should be filed
- here in this repository and use the label `core-rules`.
-
-- Anything else, such as feature requests not related to existing core rules
- functionality, should also be filed in this repository but without the
- `core-rules` label.
-
(breaking-changes)=
## Breaking Changes
diff --git a/DEVELOPING.md b/DEVELOPING.md
index dfca9844f7..360c57a4b3 100644
--- a/DEVELOPING.md
+++ b/DEVELOPING.md
@@ -17,71 +17,11 @@
# bazel run //tools/private/update_deps:update_coverage_deps 7.6.1
```
-## Releasing
-
-Start from a clean checkout at `main`.
-
-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.
-
-### Releasing from HEAD
-
-#### Steps
-1. [Determine the next semantic version number](#determining-semantic-version).
-1. Update CHANGELOG.md: replace the `v0-0-0` and `0.0.0` with `X.Y.0`.
-1. Replace `VERSION_NEXT_*` strings with `X.Y.0`.
-1. Send these changes for review and get them merged.
-1. Create a branch for the new release, named `release/X.Y`
- ```
- git branch --no-track release/X.Y upstream/main && git push upstream release/X.Y
- ```
-1. Create a tag and push:
- ```
- git tag X.Y.0 upstream/release/X.Y && git push upstream --tags
- ```
- **NOTE:** Pushing the tag will trigger release automation.
-1. Release automation will create a GitHub release and BCR pull request.
-
-#### Determining Semantic Version
-
-**rules_python** uses [semantic version](https://semver.org), 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.
-
-To find if there were any features added or incompatible changes made, review
-[CHANGELOG.md](CHANGELOG.md) and the commit history. This can be done using
-github by going to the url:
-`https://github.com/bazelbuild/rules_python/compare/...main`.
-
-### Patch release with cherry picks
-
-If a patch release from head would contain changes that aren't appropriate for
-a patch release, then the patch release needs to be based on the original
-release tag and the patch changes cherry-picked into it.
-
-In this example, release `0.37.0` is being patched to create release `0.37.1`.
-The fix being included is commit `deadbeef`.
-
-1. `git checkout release/0.37`
-1. `git cherry-pick -x deadbeef`
-1. Fix merge conflicts, if any.
-1. `git cherry-pick --continue` (if applicable)
-1. `git push upstream`
-
-If multiple commits need to be applied, repeat the `git cherry-pick` step for
-each.
-
-Once the release branch is in the desired state, use `git tag` to tag it, as
-done with a release from head. Release automation will do the rest.
-
-#### After release creation in Github
-
-1. Announce the release in the #python channel in the Bazel slack (bazelbuild.slack.com).
-
-## Secrets
-
-### PyPI user rules-python
-
-Part of the release process uploads packages to PyPI as the user `rules-python`.
-This account is managed by Google; contact rules-python-pyi@google.com if
-something needs to be done with the PyPI account.
+## Updating tool dependencies
+
+It's suggested to routinely update the tool versions within our repo - some of the
+tools are using requirement files compiled by `uv` and others use other means. In order
+to have everything self-documented, we have a special target -
+`//private:requirements.update`, which uses `rules_multirun` to run in sequence all
+of the requirement updating scripts in one go. This can be done once per release as
+we prepare for releases.
diff --git a/RELEASING.md b/RELEASING.md
new file mode 100644
index 0000000000..42a29219f9
--- /dev/null
+++ b/RELEASING.md
@@ -0,0 +1,68 @@
+# Releasing
+
+Start from a clean checkout at `main`.
+
+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.
+
+## Releasing from HEAD
+
+### Steps
+1. [Determine the next semantic version number](#determining-semantic-version).
+1. Update CHANGELOG.md: replace the `v0-0-0` and `0.0.0` with `X.Y.0`.
+1. Replace `VERSION_NEXT_*` strings with `X.Y.0`.
+1. Send these changes for review and get them merged.
+1. Create a branch for the new release, named `release/X.Y`
+ ```
+ git branch --no-track release/X.Y upstream/main && git push upstream release/X.Y
+ ```
+1. Create a tag and push:
+ ```
+ git tag X.Y.0 upstream/release/X.Y && git push upstream --tags
+ ```
+ **NOTE:** Pushing the tag will trigger release automation.
+1. Release automation will create a GitHub release and BCR pull request.
+
+### Determining Semantic Version
+
+**rules_python** uses [semantic version](https://semver.org), 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.
+
+To find if there were any features added or incompatible changes made, review
+[CHANGELOG.md](CHANGELOG.md) and the commit history. This can be done using
+github by going to the url:
+`https://github.com/bazelbuild/rules_python/compare/...main`.
+
+## Patch release with cherry picks
+
+If a patch release from head would contain changes that aren't appropriate for
+a patch release, then the patch release needs to be based on the original
+release tag and the patch changes cherry-picked into it.
+
+In this example, release `0.37.0` is being patched to create release `0.37.1`.
+The fix being included is commit `deadbeef`.
+
+1. `git checkout release/0.37`
+1. `git cherry-pick -x deadbeef`
+1. Fix merge conflicts, if any.
+1. `git cherry-pick --continue` (if applicable)
+1. `git push upstream`
+
+If multiple commits need to be applied, repeat the `git cherry-pick` step for
+each.
+
+Once the release branch is in the desired state, use `git tag` to tag it, as
+done with a release from head. Release automation will do the rest.
+
+### After release creation in Github
+
+1. Announce the release in the #python channel in the Bazel slack (bazelbuild.slack.com).
+
+## Secrets
+
+### PyPI user rules-python
+
+Part of the release process uploads packages to PyPI as the user `rules-python`.
+This account is managed by Google; contact rules-python-pyi@google.com if
+something needs to be done with the PyPI account.