1# For Developers 2 3## Updating internal dependencies 4 51. Modify the `./python/private/pypi/requirements.txt` file and run: 6 ``` 7 bazel run //private:whl_library_requirements.update 8 ``` 91. Run the following target to update `twine` dependencies: 10 ``` 11 bazel run //private:requirements.update 12 ``` 131. Bump the coverage dependencies using the script using: 14 ``` 15 bazel run //tools/private/update_deps:update_coverage_deps <VERSION> 16 # for example: 17 # bazel run //tools/private/update_deps:update_coverage_deps 7.6.1 18 ``` 19 20## Releasing 21 22Start from a clean checkout at `main`. 23 24Before running through the release it's good to run the build and the tests locally, and make sure CI is passing. You can 25also test-drive the commit in an existing Bazel workspace to sanity check functionality. 26 27### Releasing from HEAD 28 29#### Steps 301. [Determine the next semantic version number](#determining-semantic-version) 311. Create a tag and push, e.g. `git tag 0.5.0 upstream/main && git push upstream --tags` 32 NOTE: Pushing the tag will trigger release automation. 331. Watch the release automation run on https://github.com/bazelbuild/rules_python/actions 341. Add missing information to the release notes. The automatic release note 35 generation only includes commits associated with issues. 36 37#### Determining Semantic Version 38 39**rules_python** is currently using [Zero-based versioning](https://0ver.org/) and thus backwards-incompatible API 40changes still come under the minor-version digit. So releases with API changes and new features bump the minor, and 41those with only bug fixes and other minor changes bump the patch digit. 42 43To find if there were any features added or incompatible changes made, review 44the commit history. This can be done using github by going to the url: 45`https://github.com/bazelbuild/rules_python/compare/<VERSION>...main`. 46 47### Patch release with cherry picks 48 49If a patch release from head would contain changes that aren't appropriate for 50a patch release, then the patch release needs to be based on the original 51release tag and the patch changes cherry-picked into it. 52 53In this example, release `0.37.0` is being patched to create release `0.37.1`. 54The fix being included is commit `deadbeef`. 55 561. `git checkout -b release/0.37 0.37.0` 571. `git push upstream release/0.37` 581. `git cherry-pick -x deadbeef` 591. Fix merge conflicts, if any. 601. `git cherry-pick --continue` (if applicable) 611. `git push upstream` 62 63If multiple commits need to be applied, repeat the `git cherry-pick` step for 64each. 65 66Once the release branch is in the desired state, use `git tag` to tag it, as 67done with a release from head. Release automation will do the rest. 68 69#### After release creation in Github 70 711. Announce the release in the #python channel in the Bazel slack (bazelbuild.slack.com). 72 73## Secrets 74 75### PyPI user rules-python 76 77Part of the release process uploads packages to PyPI as the user `rules-python`. 78This account is managed by Google; contact rules-python-pyi@google.com if 79something needs to be done with the PyPI account. 80