Thanks, and sorry for mischaracterization. Glad to hear it’s different than I (wrongly) assumed. I’m curious though, if the design goals never changed and there was very little breaking changes, why the version is that high then? Not that you can’t use any numbering scheme you like, and not that semver is mandatory for every project. In hindsight I think my reaction came from assuming you use semver.
I usually bump the major version number anytime I introduce important new functionality, major performance improvements, or a major new design change. While the API hasn't changed in years, the underlying implementation and file layout can change a lot between major versions. I want to communicate that.
Also rqlite doesn't support seamless downgrades between major versions, only seamless upgrades. I want to communicate that too (I've put a lot of work into the backup-and-restore system[1] so users can protect themselves if they are concerned about the seamless upgrade failing on them).
So by bumping the major version it helps people understand that they are upgrading to a substantially different version of rqlite, even if their client code doesn't have to change at all.
