Documenting release process

[thundergolfer]

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]

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]

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.

[alexeagle]

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.

[thundergolfer]

5. Need to ping a Google person to get the release added to bazel mirror. See: Add rules_python to mirror.bazel.build #400

[thundergolfer]

Closing as this work can now be tracked in #428