3 ms·

The thing I find most frustrating about semantic version is that even under the strictest adoption it overly legitimizes breaking changes across major versions.

The thing I find most frustrating about semantic version is that even under the strictest adoption it overly legitimizes breaking changes across major versions. I see far too much refactoring of JS library APIs that is essentially aesthetic across major versions - D3 and Angular spring immediately to mind (I understand the scalability justification for Angular; I just don't really believe it). To me, having an elegant API is not the highest concern because what I'm interested in is building products, and from that point of view stability is much more important. I do not appreciate a committee of J Random JavaScript Developers randomly dumping extra work into my product backlog because they didn't like the cut of an API's jib, especially when these people have gone absolutely out of their way to drive adoption in the first place. To give a counter-example: .NET code I wrote in the mid-noughties whilst working at Red Gate still runs today, substantially unmodified. Some of that stuff is 11 or 12 years old. SQL Dependency Tracker is the most obvious example, because the product hasn't changed much since 2006, except for additions to support new object types in new versions of SQL Server. The fact that new .NET versions haven't broken the product has obviously made it much easier to support through the years.

gizmo686 9y ago
That is the entire point of the major version. The fact is, developers sometimes make breaking changes (sometimes for good reasons, sometimes for bad), and we want a standard way of documenting that. If you don't make breaking changes, than stay on 1.X.Y forever. If your project is only a year old and already on version 10.0.0, you are probably doing something wrong; but at least documenting it in your version numbers.
- bartread 9y ago
  Certainly take your point, and maybe it's in part down to my background, where a new major version generally includes some large chunk of new functionality (regardless of whether or not there are breaking changes). And really I suppose you don't ever need to go beyond version 1.x.y. Window Maker is quite a good example of this: latest version is 0.95.8 after 20 years of development.
fenomas 9y ago
What in the world does this complaint have to do with SemVer? If a library owner changes their API, all SemVer does is make sure you know about it. Are you saying that if they didn't follow SemVer they wouldn't change their API?
- bartread 9y ago
  I said it in the first line: it encourages and legitimises breaking changes. You could argue that all it does is provide a framework for managing versioning in the presence of breaking changes but that isn't what I see.
  - fenomas 9y ago
    I think you have the cart and horse the wrong way around. SemVer doesn't say that it's okay to break compatibility in major version updates, it defines "major version update" to mean "any update which breaks compatibility". If a piece of software hasn't broken compatibility but still wants to tell people they've passed a big feature milestone, it's perfectly reasonable (and I think explicitly encouraged) to have separate user-facing and semantic versions - so you tell people it's "Foo 2.0" but publish it to npm as foo@1.37.0. This is right and proper because the semver number exists solely to describe whether an update adds features and breaks compatibility or not; anyone using it otherwise is misusing semver.

gizmo686 9y ago

That is the entire point of the major version. The fact is, developers sometimes make breaking changes (sometimes for good reasons, sometimes for bad), and we want a standard way of documenting that. If you don't make breaking changes, than stay on 1.X.Y forever. If your project is only a year old and already on version 10.0.0, you are probably doing something wrong; but at least documenting it in your version numbers.

bartread 9y ago
Certainly take your point, and maybe it's in part down to my background, where a new major version generally includes some large chunk of new functionality (regardless of whether or not there are breaking changes). And really I suppose you don't ever need to go beyond version 1.x.y. Window Maker is quite a good example of this: latest version is 0.95.8 after 20 years of development.

fenomas 9y ago

What in the world does this complaint have to do with SemVer? If a library owner changes their API, all SemVer does is make sure you know about it. Are you saying that if they didn't follow SemVer they wouldn't change their API?

bartread 9y ago
I said it in the first line: it encourages and legitimises breaking changes. You could argue that all it does is provide a framework for managing versioning in the presence of breaking changes but that isn't what I see.
- fenomas 9y ago
  I think you have the cart and horse the wrong way around. SemVer doesn't say that it's okay to break compatibility in major version updates, it defines "major version update" to mean "any update which breaks compatibility". If a piece of software hasn't broken compatibility but still wants to tell people they've passed a big feature milestone, it's perfectly reasonable (and I think explicitly encouraged) to have separate user-facing and semantic versions - so you tell people it's "Foo 2.0" but publish it to npm as foo@1.37.0. This is right and proper because the semver number exists solely to describe whether an update adds features and breaks compatibility or not; anyone using it otherwise is misusing semver.