Post details
We’re introducing calendar-based versioning for our REST API, so we can keep evolving our API, whilst still giving integrators a smooth migration path and plenty of time to update their integrations.

We’re introducing calendar-based versioning for our REST API, so we can keep evolving our API, whilst still giving integrators a smooth migration path and plenty of time to update their integrations.
I've been bitten by pinning to latest versions before and definitely agree that where possible we should make sure that things are pinned exactly.
Then we can use tools like Whitesource Renovate / Dependabot to manage updates automatically.
a fun detail is that just about all programs written against that libcurl release can still be used unmodified with the latest libcurl release...
Daniel 🥌 Stenberg (@bagder)Sat, 21 Aug 2021 14:40 +0000
Best explanation of SemVer I've seen yet: FAILS.FEATURES.BUGS
Post details
Absolutely. The thing about semver major version numbers are that they don't mean new stuff, they're a permanent reminder of how many times you got the API wrong. Semver doesn't mean MAJOR.MINOR.PATCH, it means FAILS.FEATURES.BUGS
Will McGugan (@willmcgugan)Fri, 06 Aug 2021 16:13 +0000
Simon Willison (@simonw)Fri, 06 Aug 2021 16:21 +0000
Absolutely. The thing about semver major version numbers are that they don't mean new stuff, they're a permanent reminder of how many times you got the API wrong. Semver doesn't mean MAJOR.MINOR.PATCH, it means FAILS.FEATURES.BUGS
Will McGugan (@willmcgugan)Fri, 06 Aug 2021 16:13 +0000
Why I Consistently Reach for Server-Driven Content Negotiation (For Versioning) (5 mins read).
Why I use server-driven content negotiation for APIs to allow for versioning and allowing different representations of APIs.
You're currently viewing page 1 of 1, of 25 posts.