Skip to content

Conversation

AttilaTheFun
Copy link
Contributor

Instead of relying on the transition to set the flag throughout the dependency graph, users should set library_evolution = True on the specific libraries that they want to support library evolution.

PiperOrigin-RevId: 629760009
(cherry picked from commit 24a862d)

@brentleyjones
Copy link
Collaborator

Hmm, this is a breaking change, right?

Instead of relying on the transition to set the flag throughout the dependency graph, users should set `library_evolution = True` on the specific libraries that they want to support library evolution.

PiperOrigin-RevId: 629760009
(cherry picked from commit 24a862d)
@AttilaTheFun
Copy link
Contributor Author

@brentleyjones You already cherry-picked the removal of the build config from rules_swift, so the head of rules_apple is now incompatible with the head of rules_swift without this change.

We either need to revert the change in rules_swift, or apply this change to rules_apple from upstream.

@brentleyjones
Copy link
Collaborator

Sure, we need this, but I'm wondering if it means a 4.0 version bump.

@AttilaTheFun
Copy link
Contributor Author

How do you view what counts as a breaking change?

If we cut a new version of rules_apple for this, I'd argue we'd need a new version of rules_swift, too. It was actually that breakage that necessitated this one.

@brentleyjones
Copy link
Collaborator

How do you view what counts as a breaking change?

If people upgrade to a version of rules_apple that have this change and it breaks their builds.

@aaronsky
Copy link
Contributor

aaronsky commented May 4, 2025

@AttilaTheFun looks like there are some test failures that need to be fixed before we can land this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants