Remove old prerelease caveats from cloud packages page#1252
Remove old prerelease caveats from cloud packages page#1252timsneath wants to merge 1 commit intoswiftlang:mainfrom
Conversation
timsneath
changed the title
| 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. |
There was a problem hiding this comment.
Swift OPA still is pre-1.0: https://github.com/open-policy-agent/swift-opa
There was a problem hiding this comment.
Oh, interesting. I know you're authoritative :) but I couldn't find any reference to it being still a pre-release.
- Neither https://www.openpolicyagent.org/ecosystem/entry/swift-opa nor https://www.openpolicyagent.org/ecosystem mention this
- https://blog.openpolicyagent.org/introducing-swift-opa-native-policy-evaluation-for-swift-d5136c8a662e says it's "now been released".
- https://github.com/open-policy-agent/swift-opa?tab=readme-ov-file#usage doesn't mention anything about it being not ready for production usage.
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?
There was a problem hiding this comment.
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.
|
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? |
2 participants
Remove "pre-1.0" warnings from OTel and OPA, since both are now published.