Decoupling feature releases from API changes is the best option. Your API follows strict semver, but your new features can use whatever versioning scheme you w

Decoupling feature releases from API changes is the best option. Your API follows strict semver, but your new features can use whatever versioning scheme you want, this date-based scheme is fine. So the new version is 19.1 [API 2.2]. Most of this thread is debating the relative value of using a single number to communicate feature additions vs breaking changes, but these two things are (mostly) orthogonal. So use two numbers. This even allows releases where there are awesome new features but no API changes at all!