Why not semantic versioning? #193
-
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? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
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. :) |
Beta Was this translation helpful? Give feedback.
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 …