docs: split out release steps into separate doc (#2615)

Move the steps for releasing into a separate doc.

The release steps are specific to releases, which only maintainers do.
This frees up
space in the developing docs for more general tips, tricks, and guidance
for others.

Along the way...

* Remove the text about the core rules being part of Bazel
* Put the CLA text first -- if CLAs aren't signed _before_ code is
given, it can
  result is large headaches.
* Move some more internal dev steps out of contributing docs.

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 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.

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 rules-python-pyi@google.com if
+something needs to be done with the PyPI account.