Replies: 1 comment 2 replies
-
|
Hey Keith! As you already know, I use rules_apple and rules_swift in a few bazel ecosystem projects like rules_ios - thanks for all the great work and maintaining this ❤️ . I like the idea of running on HEAD: supporting Bazel N, N+1, on the same cut as opposed to making forks. It has never been obvious what versions of rules_apple, rules_swift, and bazel will end up working together. As a solution to this in rules_ios, we test and pull versions of rules_apple and rules_swift along with rules_ios. Simply put, a developer using rules_ios can always get a working version or our fork Have you considered merging these repos back into one ever? After-all, several years ago it was one repo! I find it easier to develop and test in a mono-repo than deal with all the version/shas am proposing doing this in rules_ios to improve developer experience. |
Beta Was this translation helpful? Give feedback.
-
|
A big downside of merging rules_swift into rules_apple is that we now have to account for linux and windows a lot more (even just to say "this doesn't work" at analysis time) in rules_apple, since rules_swift supports linux and windows. Also, rules_apple only has a loose dependency on rules_swift. Would improving our new compatibility table on the rules_apple README to indicate the supported rules_swift versions help? |
Beta Was this translation helpful? Give feedback.
-
|
I think the ideal state would be that users generally point at specific rules_apple releases, which includes a version of rules_swift that is supported by the current version. In the case that you are tracking HEAD, I guess the similar kind of case applies, except that you just have to pick the HEAD shas from all the repos at the same time. In general though I assume the first approach would be preferred such that users just don't have to worry about this at all, as long as the frequency of releases is "good enough" such that they don't need things on HEAD that don't make it in for a long time. |
Beta Was this translation helpful? Give feedback.
-
We haven't been very consistent around when we create releases for rules_apple + rules_swift, partially just because it takes some work, and partially just because we know some folks just track HEAD so it doesn't really matter. What would folks prefer to see for the release cadence?
17 votes ·
Beta Was this translation helpful? Give feedback.
All reactions