René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Release version 1.0","articleBody":"This issue is for tracking the effort to release a version 1.0 of rules_python.\r\n\r\nThere are several reasons for wanting to have a major version release:\r\n  * Better communicates when breaking changes are made\r\n  * Easier support for multiple versions and backporting of functionality\r\n  * Major versions are an indicator of fitness for use.\r\n\r\nAnyways, there's a few large items to complete before a 1.0 release can be considered:\r\n\r\n* [x] Implementation is all in rules_python Starlark, not Bazel itself.\r\n* [x] Written policies that cover breaking changes, backwards compatibility, support for older rules_python versions, and supported Bazel versions\r\n  * Bazel rules are rather leaky: it's easy for implementation details to unintentionally be\r\n    visible and accessible to users, even if weren't intended so. This is especially true for\r\n    rules_python, which carries various legacy and historical behaviors.\r\n  * Requiring e.g. the latest patch or minor version release of Bazel allows us to take advantage\r\n    of newer functionality and reduce the size of the test/support matrix\r\n  * Steps necessary to introduce a breaking change (e.g. docs about how to migrate, issues to file, etc).\r\n* [x] Human friendly changelog, i.e. CHANGELOG.md in keepachangelog.org-style format.\r\n* [x] API review: reduce our API footprint to what makes sense (there's a variety of things exposed publicly that probably shouldn't be public)\r\n\r\nEDIT: additional scope\r\n\r\n- [ ] ~Rename `pip_parse` to something else.~\r\n- [x] Mark `gazelle` as experimental or splitting the versioning scheme so that it is clear that it does not have similar semver guarantees.\r\n- [x] Mark `pip.parse` APIs as experimental and to stabilize later.\r\n- [x] We should have a category of public but unstable API. Certain things should be called out: gazelle, sphinxdocs, toolchain implementation details, requirements locking?\r\n- [ ] Should we explicitly say that we would implement `bzlmod` first and `WORKSPACE` is something that needs to be supported until bazel 9 is the lowest supported version. It's OK to have new features in `bzlmod` only, but `WORKSPACE` has to be present. PRs would be welcome for `WORKSPACE` additions.\r\n- [x] Allow overriding `TOOL_VERSIONS` for the `python` bzlmod extension to have API parity.","author":{"url":"https://github.com/rickeylev","@type":"Person","name":"rickeylev"},"datePublished":"2023-08-03T23:48:48.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":17},"url":"https://github.com/1361/rules_python/issues/1361"}