3 ms·

rqlite creator here. That's a mischaracterization. rqlite has been in development for 10 years[1], it's a long-running project and its design goals have never

rqlite creator here. That's a mischaracterization. rqlite has been in development for 10 years[1], it's a long-running project and its design goals have never changed. The API hasn't changed in a breaking fashion since 2016 and rqlite has supported seamless upgrades for years now. In other words rqlite users have been upgrading from version to version for over 8 years, without having to change a single line of their code. [1] https://rqlite.io/docs/design/ https://rqlite.io/docs/design/

OskarS 2y ago
I so much more appreciate this style of version numbering compared to being eternally 0.something.
ku1ik 2y ago
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.
- otoolep 2y ago
  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. [1] https://rqlite.io/docs/guides/backup/ https://rqlite.io/docs/guides/backup/
  - ku1ik 2y ago
    Got it, this makes sense. Thanks!
- kstrauser 2y ago
  As a side note, that was a gracious way for you to reply. Nicely done.

OskarS 2y ago

I so much more appreciate this style of version numbering compared to being eternally 0.something.

ku1ik 2y ago

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.

otoolep 2y ago
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. [1] https://rqlite.io/docs/guides/backup/ https://rqlite.io/docs/guides/backup/
- ku1ik 2y ago
  Got it, this makes sense. Thanks!
kstrauser 2y ago
As a side note, that was a gracious way for you to reply. Nicely done.