underscore: Underscore does not follow SemVer

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 😦

@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?

@jdalton, class act. 😃

@akre54 Sometimes the answer to whether or not a change is breaking isn’t straight forward. In those cases context, history, and data helps. It’s fortunate that I’ve been able to use Lo-Dash as a testing ground for new features and see which changes trip up devs coming from Underscore. Underscore can in turn use that to help make informed decisions on the impact of changes.

At the very least following semver will help prevent major breaking changes from slipping into patch releases and encourage developers to think about the impact of their changes. That’s a win for everyone.

Do you think this project is a snowflake? Lo-Dash is basically Underscore++, and following semver is no problem for @jdalton.

Accepting new features:

Does it break the existing API contract?

Yes? - bump major version number. No? - bump minor version number.

Accepting bug fixes / minor patches:

Does it break existing API contract?

Yes? - bump major version number. No? - bump patch version number.

How you choose to schedule official releases is entirely up to you. Just make sure the versioning is semver compatible so you don’t break other people’s code.

To quote https://github.com/jashkenas/backbone/issues/2888#issuecomment-29076249:

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.