Allow Bazel 6 users to explicitly opt-in to rules_apple 2.x

[thiagohmcruz]

Regressed in #773

[justinseanmartin]

@thiagohmcruz and I discussed offline - This feels like a weird special behavior to have for handling the CI use-case (per this comment). I like that the proposed change makes the rules_apple 2.x support a bit more explicit in the API contract. Before this change, someone using 6.1 and accidentally getting some weird default dependencies would probably be confusing.

I think we're going to omit the Bazel version check here and have this be defaults that we know work for rules_apple 2.x based on an explicit use_rules_apple_2 = True param. We're also going to reset this back to the values used prior to #773 (rules_apple v2.5.0 and rules_swift v1.10.0) as the defaults. For CI, Thiago is going to mutate the WORKSPACE file in the CI script to pass use_rules_apple_2 = True (default in the WORKSPACE will be False). Separately to this, we could bump everything to run on Bazel 6.4 as well and things should continue to work.

[luispadron]

Thank you both, that's easier to reason about

[thiagohmcruz]

@justinseanmartin To confirm the sed to use rules_apple 2.x on CI + Bazel 6.1.2 is working I checked the events here and saw this:

  {
    "id": {
      "fetch": {
        "url": "https://github.com/bazelbuild/rules_apple/releases/download/2.5.0/rules_apple.2.5.0.tar.gz"
      }
    },
    "fetch": {
      "success": true
    }
  },

[justinseanmartin]

It might be worth adding a comment on on the elsif block and updating the one on the else block. You technically don't need to specify load_rules_apple_2_dependencies in order to load the rules_apple 2.x, given the _maybe()'s, this is just a convenience for folks that want to use the defaults and making the rules_apple 2.x support a bit more clear in the API contract.

[mattrobmattrob]

Think this should be a major version bump since we're changing the public API? I'm curious how many folks are using this definition vs. the maybe support outside of Block.

[luispadron]

Think this should be a major version bump since we're changing the public API? I'm curious how many folks are using this definition vs. the maybe support outside of Block.

I personally wouldn't consider that public api, IMO it shouldn't have been merged to begin with since again users in Bazel can simply define the version they want to use. I think this PR is better than what we have right now as it makes it more clear but ideally, we wouldn't have this at flag all.

If we wanted to test in CI with 6.x and rules_apple 2 we can configure that in CI

[thiagohmcruz]

+1 to treating this as an improved contract but not necessarily a major version bump (no strong opinions though if folks want to do so). To hard code it to "Bazel 6.1.x" was a bit hack-y and would make folks on that version hit rules_apple 2.x without them knowing.

With this new flag at least it's now an opt-in for "I'm using whatever Bazel version <=6.x.x and I want to use rules_apple 2.x".

[mattrobmattrob]

I don't feel strongly. Please just call it out in the release notes. 🙏