Skip to content

Conversation

@timsneath
Copy link
Contributor

@timsneath timsneath requested a review from a team as a code owner December 1, 2025 22:51
@timsneath timsneath changed the title Remove old prerelease caveats Remove old prerelease caveats from cloud packages page Dec 1, 2025
link: https://github.com/swift-server/swift-prometheus
- name: Swift OPA
text: Evaluate Open Policy Agent IR Plans compiled from Rego declarative policy. (pre-1.0 release)
text: Evaluate Open Policy Agent IR Plans compiled from Rego declarative policy.
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, interesting. I know you're authoritative :) but I couldn't find any reference to it being still a pre-release.

In any event, I wonder if this really is the place to track its status -- any of the above URLs would probably a better place to describe its status, since they're the places that will get updated with a change?

Copy link
Member

Choose a reason for hiding this comment

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

The project being pre-1.0 just means it doesn't have a stable API yet, so packages can't depend on it expecting a stable API for a few years.

Swift OPA doesn't appear to have any releases yet (https://github.com/open-policy-agent/swift-opa/releases), so the only way to depend on it would be branch: "main" which would prevent your package from being even tagged with a version, I believe (SwiftPM would reject it).

I think of production readiness as an orthogonal metric, some packages are solid even before 1.0, others need time to bake post-1.0. But our original note about the lack of 1.0 was to call out the lack of a stable API yet.

Whether we want to keep it I'm agnostic about, fine either way.

@timsneath
Copy link
Contributor Author

Adding @davelester too. If this really won't be a stable API for years, it's a bit worrisome...

I wonder what we're recommending -- do we think folk should be using it for production server apps? If so, how should they reference it? And where can they read about its status?

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.

2 participants