The whole point of semver is to address the issue of backward-incompatible changes breaking downstream dependencies (well, among important other things).
What Go is doing is forcing you to use Semver the way it is intended to be used; from the semver specification:
---
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
---
If you don't want to adhere to this, just cut PATCH versions and MINOR versions.
It's an absolute terrible idea though.
As annoying as it may seem, there's a lot of benefits to using semver the way it is intended to: it forces you, the developer, to think a little more about how you design your code.
The small amount of productivity you lose getting used to do the proper thing (i.e. cut MAJOR version, or spend more time designing your code so that it more forward thinking) will pay off in the long term.
The tiny amount of productivity you gain by not doing the right thing will come back to haunt you and make you wish you had been more rigorous.
His startup might be small right now, but if it becomes successful, their number of internal users might explode overnight and they'll suddenly wish they had used semver properly all along.
Personally, there is no "too small for semver". Feels like every time I've done the lazy thing and failed to bump a major, even if it's small package Foo written only by me used in Bar, also only by me, there comes a time a few weeks later of digging through to figure out what broke.
When you are crunching for a deadline, the last thing you want is "oops the tool automatically bumped all the major versions on you" when you didn't explicitly intend to. Having a dedicated flag would be nicer than grep/sed though.
How does semver handle the case where I have v2.x.y and I want to change the API but I need to experiment for a few releases?
I want to get to a v3.x.y but I need. a bunch of pre-3 major versions first.
Linux kernel used to do with odd numbers for experimental versions and even numbers for stable versions.
Go is not forcing you to use semver the way it's meant to be used. Go is adding constraints to package naming and versioning above and beyond what semver requires.
The whole point of semver is to address the issue of backward-incompatible changes breaking downstream dependencies (well, among important other things).
What Go is doing is forcing you to use Semver the way it is intended to be used; from the semver specification:
---
Given a version number MAJOR.MINOR.PATCH, increment the:
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.---
If you don't want to adhere to this, just cut PATCH versions and MINOR versions.
It's an absolute terrible idea though.
As annoying as it may seem, there's a lot of benefits to using semver the way it is intended to: it forces you, the developer, to think a little more about how you design your code.
The small amount of productivity you lose getting used to do the proper thing (i.e. cut MAJOR version, or spend more time designing your code so that it more forward thinking) will pay off in the long term.
The tiny amount of productivity you gain by not doing the right thing will come back to haunt you and make you wish you had been more rigorous.
His startup might be small right now, but if it becomes successful, their number of internal users might explode overnight and they'll suddenly wish they had used semver properly all along.