Stripe uses a date-based versioning system for its API. This means that each new version of the API is identified by a specific date, like 2023-10-16.<p>When they introduce backwards-incompatible changes to the API, they release a new version with the current date. This ensures older integrations don't break unexpectedly.<p>When you first make an API request to Stripe, your account is automatically pinned to the latest available version. This means all subsequent requests from your account will use that version by default.
You can override the version manually through a special request header or via their dashboard.<p>This is a really elegant and developer friendly approach and allows them to make changes and improve their API more frequently but at the same time, it seems to me like it's very hard to maintain internally.<p>How are they taking care of all the code branching internally without this becoming a total mess ?<p>How much overhead is involved in supporting such versioning scheme and do you think it's worth for other companies to adopt this ?
Ono approach could be using branches for development flow and tags for the releases. That way you can keep your branches "separated" from the deployed releases (deploying those commit tags).