Release Underscore 1.7.0

[akre54]

Addressing #1798. 1.6.0...15a757d

This is a fairly major release, dropping most natives support (#1525) and adding _.iteratee callbacks everywhere (#1582). Might it make sense for this to be Underscore 2.0?

[davidchambers]

"115-odd" sounds… odd. How about "100-odd" instead?

[akre54]

well _.functions(_).length is 118, so maybe "120-odd"?

[davidchambers]

Or "more than 100".

[jashkenas]

No worries, I got it.

[jashkenas]

Remember to grep the codebase for any lingering "1.6.0" -- the internal version number in Underscore itself hadn't changed. Otherwise, great stuff! I love your wording on the changelog.

[megawac]

@akre54, @jashkenas I thought in #1684 we agreed that we the next release was to be 2.0 as this is definitely a breaking version (_.template, sparse arrays, etc)

[danielchatfield]

Might it make sense for this to be Underscore 2.0?

No shit, that's how semver works.

[megawac]

Some things I noticed weren't documented in the changelog, including several breaking changes. I think 2.0 should be released ASAP, after you close the open issues. Also #1755 should be merged and released as 1.7.1 so your unit tests pass.

This had potential to be a great release, shame it was done so hastily without closing the open issues.

---

Undocumented changes

Changes (excluding new features):

• a315e9f
• _.partition: include index and and array arguments in the predicate #1593

Breaking changes from a quick look (many minor):

• Simplified _.max and _.min #1423
• respect iterator return value of Infinity/-Infinity in _.min/_.max #1606
• fix treatment of null/undefined destination in _.defaults and _.extend #1607
• Breaking: Optimization for compose #1700
• Simplify chain #1691
• More consistent matches behaviour #1723
• Matches keeps an internal reference to spec object #1730
• Fixes #1739 - _.extend check for own properties #1770

[akre54]

Right. #1770 is pretty huge, I missed that one.

@danielchatfield In case you've forgotten underscore doesn't follow semver. Now wouldn't be a terrible time to start though.

[megawac]

Yeah its massive (1.6.0...1.7.0), I'd be 👍 for 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

[danielchatfield]

@akre54 Well it is released, and largely consumed, via npm which mandates the use of semver. I'd be ok with a slight deviation from the semver rules, but not releasing loads of (originally undocumented) breaking changes with just a "minor" bump.

Whatever your opinion of semver is, it is being used by npm to determine compatibility and this release broke a lot of stuff.

edit: in fact every single package manager that underscore is released to uses semver.

[lukeasrodgers]

While I'm aware that underscore doesn't follow semver, it would be nice if there was some logic to the release numbers. AFAICT the change to 1.6.0 had few breaking changes, whereas this seems to have many.

Why use release numbers at all if a) they do not follow a predictable pattern for devs, so we just have to scour the changelog anyway and hope all breaking changes are mentioned there, and b) they do not follow a predictable pattern for automated compatibility computing.

[jashkenas]

@danielchatfield & @lukeasrodgers — What exactly ended up breaking for you guys?

[danielchatfield]

#1804

[megawac]

DamonOehlman/grunt-rigger#10 and several other libs as well

[lukeasrodgers]

@jashkenas not sure when _.max([1, NaN]) behaviour changed, but that would break some of my code (and also seems contrary to native implementation and one of the main uses of NaN, i.e. propagating math errors through code). I have been bitten by changes like #1804 before as well.

I don't mean to gripe, and am grateful for all of the underscore contributors' hard work, it just seems like a more consistent approach to versioning would solve some problems for some people at least some of the time, and cause no problems for any people ever.

[Dashue]

Gogo Semver get on the cool train guys :D

No but seriously, that would help consumers immensely so please consider starting to use it.

[megawac]

@lukeasrodgers #1423.

---

The remaining changes I mentioned still need to be documented