One option that is missing from this (very informative) guide is – don’t version the API.
One can find various articles about the downsides of versioning, whichever option is chosen. It should not be foregone conclusion that your API must have versioning. One counter-example to consider is at API Versioning: What Is It and Why Is It So Hard?
Most APIs don’t need versioning; they need the ability to support compatible changes over time (not as flashy a term, right?).
…
The most effective change-compatible APIs can continue to add features without ever breaking already existing API consumers—even ones created years ago. The least effective API changes require all API producers and consumers to rewrite and re-release their code each time the API design is updated.The key to success is to design-in support for compatible changes from the very start.
…
And sometimes these API consumer teams don’t want or need the new features anyway.
…
If you’re committed to releasing breaking changes, you also need to commit to side-by-side release, documentation, online support, and so on.
Make every effort to avoid making breaking changes. Follow the 3 rules advocated in the above blog. API clients will appreciate it.