A request for API-Version header on API requests: support also “stable”, “preview” and “deprecated” for version identifiers.
Hey Cody - what do you need it for?
We intentionally didn’t support this because we want to encourage our community to reference specific versions when they need to (and when they don’t, to default to stable).
just go ahead and delete it. Not a big enough deal to even expend the effort explaining for something im 99% sure won’t happen based on your reply.
Hey Cody, sorry if my response sounded dismissive; didn’t mean it that way.
Just wanted to know where you’re coming from, and if we were missing a valid use case…
Canary deployments of our app backend. Private copies of the apps would be used in lieu of the public ones (different URLs of course). These would be used as part of testing boards and “live” in our account(s) to detect failures as new versions are released.
Its easy enough to work around though. It just means advancing versions on the canaries becomes manual, rather than automated, requiring deploying new templates. The goal is detecting breaking issues as soon as possible.
Using a version ID though is critical for anything production of course. Ideally production should always be on stable, but that’s not always possible.
1 Like
Aha, thanks for the context – basically, to automatically check the next version for compatibility with your app!
Will review it with the team and get back to you.
If it is implemented, have the sdk client log warnings to the console when when its initialized with “development” or “preview”! (or called with it and it wasn’t initialized with it).