Release 0.6.0

[ahumesky]

Release 0.6.0 is expected to comprise:

1. Starlark implementations of all rules
2. Starlark implementations of all providers
3. Tools migrated from the Bazel repo to the rules_android repo
4. Compatibility with {linux, mac, windows} x {bzlmod, WORKSPACE} x {bazel 6, bazel 7, bazel 8}
5. No longer requiring --experimental_enable_android_migration_apis / --experimental_google_legacy_api
6. Remove the "this doesn't work" disclaimer in the README

[ahumesky]

The current status is:

• All rule implementations are complete (except for a small handful of "native" calls for specific things that don't have Starlark equivalent APIs)

• All providers except ProguardSpecsInfo have been moved to Starlark, because the native version of ProguardSpecsInfo is actually in the Java rules. There is now a Starlark version of ProguardSpecsInfo in rules_java that we can migrate to, but this may or may not be in 0.6.0

• All Android tools have been moved out of bazel, however due to an array of dependency / logistics issues many of the tools rely on the "remote android tools" package that is built out of the bazel repo instead of the dependencies living / being defined in rules_android. This will be addressed in future updates

• Current compatibility for rules_android is {linux, mac, windows} x {bzlmod} x {bazel 7, bazel 8}.

  • WORKSPACE with Bazel 8 requires updating many dependent repositories (rules_java, protobuf, rules_go, gazelle, bazel itself, etc), mainly due to Bazel 8 removing java, proto, python, and shell rules. The impact is mitigated by 'autoloads' of Starlark rules for BUILD file which do not explicitly load these rules, but this does not cover all use cases. Work is ongoing to make each piece work with the other @comius
  • Bazel 6 support, motivated at present primarily for rules_jvm_external compatibility goals, is not yet tested @jin @shs96c