REDDIT 原始帖子
how do you version a public js sdk when customers never update the script tag?
we ship from a single cdn url so every fix goes live for everyone instantly, which is great until a css change breaks someone's layout at 2am. thought about pinning versions per-customer but then we're supporting five builds forever and nobody upgrades on…
we ship from a single cdn url so every fix goes live for everyone instantly, which is great until a css change breaks someone's layout at 2am. thought about pinning versions per-customer but then we're supporting five builds forever and nobody upgrades on their own. anyone found a middle ground that doesn't turn into permanent long-tail maintenance?
已收录讨论
The middle ground is usually not per-customer permanent versions; it is channel plus contract. I would keep one stable loader URL, but make the loader choose a versioned asset behind the scenes based on a customer config you control. Something like: default channel: current stable build canary channel: a small set of friendly accounts pinned channel: temporary hold for accounts that broke deprecation date on every pinned override rollback switch that moves everyone back to the previous stable build Then treat the SDK surface like an API contract. A CSS change should not be able to depend on the host page by accident. Shadow DOM, prefixed classes, explicit container sizing, and visual regression tests against ugly customer pages matter more than the versioning scheme. The key is making pinning an incident tool, not a product tier. If a customer is pinned, there should be an owner and an expiration date.
The least awful middle ground I’ve seen: keep /latest only for truly backwards-compatible fixes, but let customers pin a major line like /v2/sdk.js. Then do migrations by cohort with a kill switch and a deprecation window. Supporting five builds forever is how a simple SDK turns into archaeology. But shipping every CSS change to everyone at 2am is also how you earn exciting Slack messages.
the piece that decides whether that rollback switch actually works is cache headers. if the loader url is sitting in a cdn or browser cache for a day, flipping the channel doesn't reach the broken customer until tomorrow. short max-age on the loader, long immutable caching on the versioned assets underneath. the other thing worth guarding is loader creep. once the loader is effectively unversionable, anything that sneaks into it is a change you cannot roll back, so it has to stay boring and tiny.
the piece that decides whether that rollback switch actually works is cache headers. if the loader url is sitting in a cdn or browser cache for a day, flipping the channel doesn't reach the broken customer until tomorrow. short max-age on the loader, long immutable caching on the versioned assets underneath. the other thing worth guarding is loader creep. once the loader is effectively unversionable, anything that sneaks into it is a change you cannot roll back, so it has to stay boring and tiny.