Underscore does not follow SemVer

[wavebeem]

It would be extremely useful if Underscore followed Semantic Versioning. It currently does not, as things like breaking bindAll and removing unzip have occurred without major version bumps.

This would allow library consumers to upgrade bugfixes and performance improvements and gain additional functions without fear of code breaking.

[akre54]

To quote jashkenas/backbone#2888 (comment):

Thanks, but strictly following "semantic" versioning wouldn't work out very well for Backbone. Given that the project is almost all surface area, and very little internals, almost any given change (patch, pull request) to Backbone breaks backwards-compatibility in some small way ... even if only for the folks relying on previously undefined behavior.

The rest of the comment is worth a read too, even if you disagree.

[akre54]

jashkenas/coffeescript#3352 (comment) too

[jdalton]

@akre54 I'm curious what your thoughts are on the fact that others projects like Lo-Dash (Underscore alternative) and ExosJS (Backbone alternative) can follow semver?

Since those drop-in replacements can follow semver doesn't that kind of throw a wrench in the excuse pushed by Underscore/Backbone core?

[akre54]

Couple things.

Lo-Dash, for the most part, sticks to the cowpaths paved by Underscore, so it has the advantage of holding off until an Underscore release to push a version bump for feature parity. The differences from Underscore tend to be more in the enhancements category and less in significant breaking changes.

Lo-Dash adds much more guard code for bc at the expense of code clutter while Underscore strives for terseness. It's easier to get away with a few lines of extra code when the library is larger to begin with (Lo-Dash clocks in at 8.7k lines vs 1.4k for Underscore.) There's also much more internal mucking that can be done in Lo-Dash since so much of the logic is internal.

It's also written disproportionately by one contributor (you), whereas Underscore's changes tend to come from a much more diverse set of contributors, meaning new features can come at any time, and sometimes big feature changes and backward-incompatible changes come at inopportune moments to a release schedule.

Anecdotally, I get the feeling Underscore also has the release-schedule disadvantage of being used in many more beginner projects than Lo-Dash (by its very nature, Lo-Dash tends to appeal to devs who need its power). A more advanced dev is going to be more comfortable dealing with the fallout from breaking changes, and may understand their reasoning a bit more.

Lastly, as the co-author and lead contributor of Exoskeleton, I'll be the first to tell you we haven't been following semver either. We also have the advantages of Lo-Dash as described above.

[jdalton]

Lo-Dash, for the most part, sticks to the cowpaths paved by Underscore, so it has the advantage of holding off until an Underscore release to push a version bump for feature parity. The differences from Underscore tend to be more in the enhancements category and less in significant breaking changes.

What does that have to do with Underscore's version strategy? Lo-Dash bumps versions following semver which is why it's at v2.x going on v3.x.

Lo-Dash adds much more guard code for bc at the expense of code clutter while Underscore strives for terseness.

What does guard code or being terse have to do with version strategy?

It's easier to get away with a few lines of extra code when the library is larger to begin with (Lo-Dash clocks in at 8.7k lines vs 1.4k for Underscore.)

Lo-Dash has inline docs, LOC isn't relevant to versioning.

There's also much more internal mucking that can be done in Lo-Dash since so much of the logic is internal.

Can't the same be said for Underscore?

It's also written disproportionately by one contributor (you), whereas Underscore's changes tend to come from a much more diverse set of contributors, meaning new features can come at any time, and sometimes big feature changes and backward-incompatible changes come at inopportune moments to a release schedule.

That's why Underscore has maintainers to accept/reject or push off until a future release.
Again, not relevant to versioning.

Anecdotally, I get the feeling Underscore also has the disadvantage of being used in many more beginner projects than Lo-Dash (by its very nature, Lo-Dash tends to appeal to devs who need its power).

I disagree, Lo-Dash has thousands of dependents and all can't be experts with it.

A more advanced dev is going to be more comfortable dealing with the fallout from breaking changes, and may understand their reasoning a bit more.

Because Lo-Dash follows semver devs don't have to deal with fallout until they jump to a major version update. Unlike Underscore, Lo-Dash won't change from under their feet because they used a ~ for the package's version range.

Lastly, as the co-author and lead contributor of Exoskeleton, I'll be the first to tell you we haven't been following semver either.

Then you should remove that from its marketing.

I don't think there's any reason why Underscore couldn't follow semver.
Not following it is a disservice to your users 😦

[ericelliott]

If you want to be included in npm or bower, it's not up for debate. You must use semver. You're making an implicit promise to follow semver, and if you don't, that breaks people's code without warning, and that's frowned on by pretty much everybody.

We're talking about a choice that breaks production code. It's not cool to play a sloppy game with other people's time and money.

That means your version numbers get bigger faster. So what? It's a number. That's far better than breaking somebody's production shopping cart.

[oriSomething]

+1 for semver

[raganwald]

Personally, I don't think it's "cool" to get personal in a bug report. Either it does or it doesn't follow semantic versioning. Here are the reasons--bang, bang, bang--why it would be an even better library if it did. Here are the reasons--bang, bang--why it's feasible for the maintainers to increment the version number in a manner congruent with semver.

After that, it's up to the maintainers. If you disagree with their stance, there are alternative libraries to use.. You can fork the project (as others have done). You can write a blog post getting as personal as you please.

But let's try to have civil disagreement.

[ericelliott]

I don't understand @raganwald. Who's getting personal?

I'm not attacking anybody. I'm pointing out that semver is part of the API contract you enter into when you publish a package to npm or bower.

If you break that contract, you break other people's code. That's not cool.

npm works really well because we all agree on a few rules that keep our modules working well with each other. If you break those rules, you break other modules that try to work with yours. You break production apps that rely on your code.

The question is not "should we use semver?" The question is, "do we want to be good citizens in this ecosystem?"

[akre54]

The key point is that on a project like Underscore, every change is breaking to someone. If we remove a null guard from _.extend (to use a random example) because it's causing a bug for someone, and it creates a bug for someone else, is that a patch? Is that a minor version? Major?

For Underscore and Backbone, I don't think it's unreasonable to pin your dependencies. Following semver isn't a requirement to publish to a packager.

[jdalton]

The key point is that on a project like Underscore, every change is breaking to someone.

You're jumping to an extreme to justify your position. The reality is it's a balance. There's popular API, edge cases, and documented behavior. It's very possible to go for a stretch of time w/o bumping a major version by simply fixing bugs and adding functionality.

What it means is the maintainers have to think and plan. This means you may have to create a roadmap for features or changes that can't be tackled w/o breaking back-compat and that's fine.

Underscore has bumped patch releases and introduced major breaking changes. This is something the maintainers can totally control.

For Underscore and Backbone, I don't think it's unreasonable to pin your dependencies.

There should be a message/warning in the documentation for sure.

[ericelliott]

@akre54 Changing undocumented features or undocumented bugs may break code that relies on those, but users rely on undocumented features and bugs at their own peril.

Ignoring semver puts every user of your API in peril. People fix bugs in large open source projects that follow semver all the time, but it's really rare to see large version numbers in the npm ecosystem.

Why is that?

Because all good APIs follow the open/closed principle (open for extension, closed for breaking changes) as closely as they reasonably can, so that users can keep pace with the API, and changes don't break existing code.

[braddunbar]

To add to the anecdotes, my code has also been broken by Underscore bumps in the past. We've resorted to committing node_modules to prevent it because --save --save-exact doesn't cut it. If a second-level dependency relies on Underscore and uses a ^x.y.z version then your app is still broken.

As for version numbers indicating progress, I don't care. Using version 2.1.3 or 143.3.2 makes no difference to me. Library progress and maturity are not measured in version numbers. I just don't want a phone call on Sunday afternoon because someone updated a dependency that relies on underscore@^x.y.z.