Why not semantic versioning?

[chrisjsewell]

Personally, I think calendar versioning is an awful idea for a library package, but I will try to keep an open mind 😜

In particular, what would one pin to in their requirements, to have a "reasonable" expectation of no breaking changes?

[pradyunsg]

Oh man, I don't wanna write an essay, so I'm gonna timebox writing this to 10 minutes.

I don't think this is a library project -- the users of this projects aren't using this as an API where they need clear guarantees of backwards compatibility. SemVer, for all its flaws, does a decent job on that front. There's no clear API to be changing here so... semver-style versioning is difficult to apply.

I want to make promises around compatibility in terms of calendar time, with a clear communication of "yes, this is supported" -- because I think this will work better for this project. It is mainly a visual-design thing and not a code-based library. The planned approach here is something that I consider to be straightforward to explain to users -- no major design changes in {period} and here's how you pin to versions in a period. If you wanna upgrade beyond that, there may be design changes.

This is somewhat like having a "major" semver release every {period}; except as I said, "what is the backwards compatibility of a documentation theme" is a fuzzy question that I don't wanna argue with users because I made a change they think is incompatible and I don't.

Something similar to the approach I'm taking here will also work for libraries with tweaks IMO -- but that's a different conversation.

This approach requires much less negotiation with users over "is this a major or minor change?", clarifies that there is responsibility on the user's end to ensure compatibility during upgrades and makes it very straightforward for me to make a backwards-incompatible change if I deem it necessary for the project -- as it stands, this project effectively dies if I'm not interested in it, so anything that makes it more likely that I stay interested in it, will keep this project actively-maintained longer. :)

And, there goes my 10 minutes. :)

[pradyunsg]

Oh, and this also means that if I come back to the project after {period}, I will have a fair amount of flexibility to make changes -- with the contract with the users being that this is fine. Users are already placing trust in the project by using it and (hopefully) continuing to do so.

I don't have any reasonable incentive to completely redo things here, but I might wanna make not-so-minor changes every so often that certain users won't like -- and in that case, I want it to be OK that my answer to them will sometimes be "I am not adding knobs / taking additional workload to account for your preferences or 'bring back the old thing' or whatever.". That isn't to say that would be my answer always but it is important that I have that.

And forcing the project away from semver-style promises enables this.

[chrisjsewell]

Yeh no worries, just interesting in your thinking 👍
We will agree to disagree on some points lol, but yeh don’t want to get into a big discussion about it