That is a great question. But we can all agree that semver is missing some crucial points. I am also a victim of this. I released a CSS framework (amigocss.com) a few months ago. Soon I realized I did make a typo of a few classes...i.e border-radious instead of border-radius. Semver now requires me to do another push and name it as 2.0.0 almost a few hours after releasing 1.0.0. That's a problem! A big problem! Yes it's a breaking change...But if someone ask you "I see you have released version 2.0.0, what's new there?" And you tell them 2.0.0 contains changes to the spelling errors...How ridiculous would that be?
Or an alternative to that is waiting a few months till you have added enough changes just to justify the 2.0.0. Meanwhile, the bug (spelling error) is still living in people's projects...and sometimes they may think that error was a feature...and when you correct it later...it's now an inconvenience.
So people misuse semver because some decisions it makes doesn't make sense. I also did butcher semver purposely because I didn't want to push my release as 2.0.0 from 1.0.0 just because of a spelling error.
I recommend a system that is forgiving. A system that understands some breaking changes aren't major releases. How about percentages? As an example...may be less than 10% should not be a major changes, etc.
But if someone ask you "I see you have released version 2.0.0, what's new there?" And you tell them 2.0.0 contains changes to the spelling errors...How ridiculous would that be?
As others have quoted, that's literally what the major version is for:
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API
That being said, you would typically not make this a breaking change by:
correcting the API
creating alias using the erroneous API method and deprecate it
This way it would be a minor change, and major change would happen only once you drop the alias. Some libraries choose to keep them for years.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How do you imagine this "new system" working?
It is either a breaking change or it is not, it is that simple.
That's mostly because semver is misused, which is the point of this article.
That is a great question. But we can all agree that semver is missing some crucial points. I am also a victim of this. I released a CSS framework (amigocss.com) a few months ago. Soon I realized I did make a typo of a few classes...i.e border-radious instead of border-radius. Semver now requires me to do another push and name it as 2.0.0 almost a few hours after releasing 1.0.0. That's a problem! A big problem! Yes it's a breaking change...But if someone ask you "I see you have released version 2.0.0, what's new there?" And you tell them 2.0.0 contains changes to the spelling errors...How ridiculous would that be?
Or an alternative to that is waiting a few months till you have added enough changes just to justify the 2.0.0. Meanwhile, the bug (spelling error) is still living in people's projects...and sometimes they may think that error was a feature...and when you correct it later...it's now an inconvenience.
So people misuse semver because some decisions it makes doesn't make sense. I also did butcher semver purposely because I didn't want to push my release as 2.0.0 from 1.0.0 just because of a spelling error.
I recommend a system that is forgiving. A system that understands some breaking changes aren't major releases. How about percentages? As an example...may be less than 10% should not be a major changes, etc.
As others have quoted, that's literally what the major version is for:
That being said, you would typically not make this a breaking change by:
This way it would be a minor change, and major change would happen only once you drop the alias. Some libraries choose to keep them for years.