docs: split out release steps into separate doc

Author: rickeylev

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 <https://cla.developers.google.com/> 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 <https://cla.developers.google.com/> 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
 

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/<VERSION>...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 [email protected] 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.

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/<VERSION>...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 [email protected] if
+something needs to be done with the PyPI account.