requiring Sendable from Baggage is source breaking

[weissi]

This commit required that types confirming to BaggageKey are now Sendable on Swift 5.5+.

That change obviously makes sense but unfortunately, it's source breaking...

That's fine by SemVer (because this package is version 0.x) but probably still an issue.

[slashmo]

Thanks for opening the issue, @weissi! 👍 I hit this breaking change in "OpenTelemetry Swift", but am updating now to account for Sendable.

That's fine by SemVer (because this package is version 0.x) but probably still an issue.

Agreed, I think it's okay to break while were in the pre-SemVer stage to move more quickly.

[weissi]

Agreed, I think it's okay to break while were in the pre-SemVer stage to move more quickly.

Sure, it's okay by the rules but breakage between 0.2.1 and 0.2.2 is still not acceptable I think. Usually, people depend on 0.x packages with upToNextMinor because breaking API usually goes into a new minor version. So I think what should happen is:

• release a 0.2.3 which reverts this change
• release a 0.3.0 which brings back the breaking change

[slashmo]

• release a 0.2.3 which reverts this change
• release a 0.3.0 which brings back the breaking change

Ah, I thought it was a minor bump. In that case, I agree with your plan to move the change to a 0.3.0. @ktoso Since you originally made the release, are you okay these steps?

[ktoso]

No reason to panic. We don't need to release a revert. Let's calmly think this through first

[ktoso]

Heh ok I read the reasoning now, ok sure we can do that. Tho that's strictly stronger guarantees than semver ever does 😉

happy with the proposed plan. I will think more how this would have had to be handled in a stable package so we can document it

[ktoso]

Doing the reverts now and I'll talk with concurrency folks how such change could be possible if a module were stable -- I guess this honestly means that users would use it with "@preconcurrency" and by itself is not a breaking change then 🤔

[ktoso]

• tagged 0.2.3 - back to basics, no Sendable
• tagged 0.3.0 with Sendable - https://github.com/apple/swift-distributed-tracing-baggage/releases/tag/0.3.0

Tho to be honest the actual solution is @preconcurrency import but that didn't land yet (well it did, but not in a release), so we need this dance for now.

Hope that works @weissi

[weissi]

• tagged 0.2.3 - back to basics, no Sendable
• tagged 0.3.0 with Sendable - https://github.com/apple/swift-distributed-tracing-baggage/releases/tag/0.3.0

Tho to be honest the actual solution is @preconcurrency import but that didn't land yet (well it did, but not in a release), so we need this dance for now.

If users have to do anything, then it’s a breaking change.
This needs to fixed another way. Users compiling with -swift-version 5 (Usually automatically derived from // swift-tools-version: <5.5) obviously shouldn’t get a new requirement because they clearly predate Concurrency.

Not sure how that’s best expressed in the source language that this should only be Sendable if the client is using a Swift language version that’s new enough.