Keep the bridge on the stable release line - #856
Conversation
The 1.0 preview covers the Worker SDK on @next. Self-deployed bridge releases stay on main with matching stable package and image versions until a separate bridge contract is ready.
|
| --- | ||
| name: sandbox-bridge | ||
| description: Trigger only when exercising a real running Sandbox deployment over HTTP via SANDBOX_WORKER_URL and SANDBOX_API_KEY, including process, terminal, file, tunnel, mount, pool, or OpenAPI bridge routes. | ||
| description: Trigger only when exercising a real running stable Sandbox bridge deployment over HTTP via SANDBOX_WORKER_URL and SANDBOX_API_KEY. |
There was a problem hiding this comment.
I don't think it's super obvious what stable means.
| description: Trigger only when exercising a real running stable Sandbox bridge deployment over HTTP via SANDBOX_WORKER_URL and SANDBOX_API_KEY. | |
| description: Trigger only when exercising a real running Sandbox bridge deployment over HTTP via SANDBOX_WORKER_URL and SANDBOX_API_KEY using the stable 0.12 version of @cloudflare/sandbox-sdk. |
There was a problem hiding this comment.
I think the language here is off, the skill is fine, it just needs a line at the top to explain that when provided the SANDBOX_WORKER_URL is pointing to a deployment of the Sandbox bridge using the 0.12 branch of the codebase and APIs documented reflect that.
Summary
Keep the self-deployed bridge on the stable/
mainrelease line while the 1.0 preview covers the Worker SDK on@next.The supported bridge remains the
maintemplate with matching stable package and image versions. This branch is no longer documented as a bridge release target.Why
The preview process/terminal HTTP surface is still contested, and a hard bridge cutover would force mixed old/new HTTP clients through a flag day. Freezing the supported bridge on stable avoids that until the bridge contract is designed separately.
Test plan
tree/next/bridge/worker