[amanzi]

Interesting timing for me since I was just reading the semver.org site just last week. I know that their proposal is to only include breaking changes in the major version, but in my experience lots of products use major versions for marketing purposes, and minor versions for functional changes including both breaking and non-breaking changes.

The important thing is to be clear in your docs about your versioning strategy. And from a quick search of the Caddy website, I couldn't find anything that explains this. Their install guide doesn't really mention versions at all, giving people no clues that a minor version change could break their sites.

[mholt]

We could improve that for sure. I am hoping to redo the website docs later this year... and will try to include some information about our development and release process.

Basically we try to put the bigger changes in the "minor" version bump (because bumping the major version introduces a lot of friction in the Go ecosystem) and encourage people to read release notes. We are open to suggestions though!

[stouset]

> in my experience lots of products use major versions for marketing purposes

This is what people are desperately hoping to change. The industry is tired of updating from 4.7.1 to 4.7.2 and having everything break. Please bring sanity to versioning, so people can have a reasonable expectation that x.y to x.z isn’t going to require days of rewriting stuff.

[yjftsjthsd-h]

> I know that their proposal is to only include breaking changes in the major version, but in my experience lots of products use major versions for marketing purposes, and minor versions for functional changes including both breaking and non-breaking changes.

The solution is one more number: Marketing.Breaking.Feature.Bugfix