Fix the versioning

[danielchatfield]

1.7.0 introduced loads of breaking changes.

The number of dependant modules which are now broken as a result is huge, personally I think that 1.7.0 should be killed (removed from npm) and 2.0 released - the longer the delay the harder it will be to do this.

underscore.js is solely consumed via package managers that mandate the use of semver, you may personally not like semver but that is what is used by the installers to determine compatibility. Last time this was brought up you stated that if you used semver then we would be on underscore version 47 now - well that is much better than having broken code everywhere and lodash has managed to keep the version number below 4.0.0 without breaking everyone's code.

[jashkenas]

I think we should leave 1.7.0 as 1.7.0. There are a lot of changes, some of which change behavior for edge cases, which justifies bumping the minor version up a notch. If you're using npm's ~ operator, you won't be automatically upgraded to 1.7.0.

But it's not really the kind of complete overhaul or massive change to the public API that justifies a 2.0. Perhaps once things are really polished and locked down.

But that said, let's leave this ticket open for discussion...

[danielchatfield]

If you're using npm's ~ operator, you won't be automatically upgraded to 1.7.0.

By default npm uses ^

[toddself]

According to Semver.org bumping the minor release should:

MINOR version when you add functionality in a backwards-compatible manner, and

If the behaviors changed do not solely constitute urgent bug fixes which were causing the edge cases to change, this is not a minor release.

Coupled with the change to NPM moving to ^ which will accept any version within a major release AND the fact that underscore is the MOST depended upon package in NPM it is likely better to resolve this issue as @danielchatfield suggests.

From your changelog:

Underscore templates no longer accept an initial data object. _.template always returns a function now.

Changing a method signature and what it returns (without it previously being deprecated) in a minor version is a pretty big deal:

> 14:21:41 ~/src/test
↳ npm i underscore
npm http GET https://registry.npmjs.org/underscore
npm http 304 https://registry.npmjs.org/underscore
npm http GET https://registry.npmjs.org/underscore/-/underscore-1.7.0.tgz
npm http 200 https://registry.npmjs.org/underscore/-/underscore-1.7.0.tgz
underscore@1.7.0 ../../node_modules/underscore
14:21:47 ~/src/test
↳ node
> var und = require('underscore');
undefined
> und.template('hello: <%= name %>', {name: 'moe'});
{ [Function]
  source: 'function(obj){\nvar __t,__p=\'\',__j=Array.prototype.join,print=function(){__p+=__j.call(arguments,\'\');};\nwith(obj||{}){\n__p+=\'hello: \'+\n((__t=( name ))==null?\'\':__t)+\n\'\';\n}\nreturn __p;\n}' }
>

Versus:

14:20:43 ~/src/test
↳ npm i underscore@1.6.0
npm http GET https://registry.npmjs.org/underscore
npm http 200 https://registry.npmjs.org/underscore
npm http GET https://registry.npmjs.org/underscore/-/underscore-1.6.0.tgz
npm http 200 https://registry.npmjs.org/underscore/-/underscore-1.6.0.tgz
underscore@1.6.0 ../../node_modules/underscore
14:20:52 ~/src/test
↳ node
> var und = require('underscore');
undefined
> und.template("hello: <%= name %>", {name: 'moe'});
'hello: moe'

[jamiebuilds]

@jashkenas I understand and respect your stance regarding semver. However, when making breaking changes I believe there is a universal expectation (that predates semver) to bump a major version. At the very least it sets expectations properly, but it will also help those who do follow semver (which is the vast majority of developers these days).

Considering how many people who depend of underscore now have broken code because of this latest release, I think it would be a good decision to do what @megawac said:

releasing 1.7.1 or 1.8 as a revert of 1.6.0 and then working on 2.0.0 for some time next week

[scottnonnenberg]

+1 on removing and replacing with 2.0.0. Rigid semver specifies that no breaking changes can appear except as a major version (unless you're below version 1.0). This has introduced mysterious breaks for me, deep in node module hierarchies. :0(

[josephspens]

This definitely just caused major issues for me. That's what I get for not thoroughly reading the changelog, but I didn't imagine a minor version upgrade would be that dangerous.

Is the solution to add backwards compatibility back into 1.7?

[spadgos]

If you're using npm's ~ operator, you won't be automatically upgraded to 1.7.0.

This really isn't the point. Semver is meant for humans just as much as machines. The entire point of semver is to give confidence to consumers of the library that they can safely upgrade, whether that happens automatically with a package manager instruction or by hand.

it's not really the kind of complete overhaul or massive change to the public API that justifies a 2.0

That's not what the major number is for though. It's for any breaking change.

[jdalton]

I'm 👍 for revising how Underscore bumps. It seems like most releases in recent memory have had some kind of hiccup with the 1.7.0 bump being the worst (failed unit tests, incomplete features, missing documentation, missing breaking change notices, and versioning that caused many projects to break). The process as it stands today isn't working.

[mathiasbynens]

Underscore is among the most popular packages on npm. The whole npm ecosystem is based on semver. Underscore should respect semver.

[webRat]

Underscore templating changes in 1.7.0 broke our project/templates and we had to revert back to 1.6.0. Pretty big / major change to the templating system alone.