Skip to content

Add explicit availability annotations #2234

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 13, 2025
Merged

Conversation

glbrntt
Copy link
Collaborator

@glbrntt glbrntt commented May 8, 2025

Motivation:

gRPC is moving from specifying the platforms in the package manifest to annotating code with availability annotations.

Modifications:

  • Explicitly annotate public API
  • Add '-require-explicit-availability' to CI
  • Drop platforms

Result:

  • gRPC can be used by packages which don't specify their platforms in the manifest

Motivation:

gRPC is moving from specifying the platforms in the package manifest to
annotating code with availability annotations.

Modifications:

- Explicitly annotate public API
- Add '-require-explicit-availability' to CI
- Drop platforms

Result:

- gRPC can be used by packages which don't specify their platforms in
  the manifest
@glbrntt glbrntt added the 🆕 semver/minor Adds new public API. label May 8, 2025
@glbrntt glbrntt requested a review from gjcairo May 8, 2025 07:12
Comment on lines +53 to +60
let nextMinorVersion = 2
let availabilitySettings: [SwiftSetting] = (0 ... nextMinorVersion).map { minor in
let name = "gRPCSwift"
let version = "2.\(minor)"
let platforms = "macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0"
let setting = "AvailabilityMacro=\(name) \(version):\(platforms)"
return .enableExperimentalFeature(setting)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we handling each minor separately (instead of just having a gRPCSwift 2 macro) in case we eventually add new APIs that have higher platform requirements?

With this logic, we tie each whole minor to a set of platforms. What if we ever decide to add some new API that requires higher platform requirements, alongside other new API which could keep the previous platform requirements? Would we just bump all of the new APIs to use the new platforms?

@glbrntt glbrntt merged commit 90d9094 into grpc:main May 13, 2025
36 checks passed
@glbrntt glbrntt deleted the v2/availability branch May 13, 2025 10:59
@glbrntt glbrntt added 🔨 semver/patch No public API change. and removed 🆕 semver/minor Adds new public API. labels May 15, 2025
dongjoon-hyun added a commit to apache/spark-connect-swift that referenced this pull request May 17, 2025
### What changes were proposed in this pull request?

This PR aims to upgrade `gRPC Swift` to 2.2.1.

### Why are the changes needed?

To bring the latest bug fixes.
- https://github.com/grpc/grpc-swift/releases/tag/2.2.1
  - grpc/grpc-swift#2234

### Does this PR introduce _any_ user-facing change?

No.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #161 from dongjoon-hyun/SPARK-52197.

Authored-by: Dongjoon Hyun <[email protected]>
Signed-off-by: Dongjoon Hyun <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔨 semver/patch No public API change.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants