Drop support for node 0.10, 0.12 and maybe more? about nanomatch

[phated]

@jonschlinkert if I were updating a 0.10 or 0.12 service, it'd be to node 4 so maybe keep that around longer than EOL? Remember that product owners can't move as fast as node core expects them to.

[wtgtybhertgeghgtwtg]

Would you use native stuff in place of packages where applicable, then? Like, Object.assign over extend-shallow, Map over map-cache?

[jonschlinkert]

I was wondering because we would do a major version anyway for the snapdragon updates

Definitely. Let's drop 4 after EOL though.

Would you use native stuff in place of packages where applicable, then? Like, Object.assign over extend-shallow, Map over map-cache?

Absolutely!

[jonschlinkert]

if I were updating a 0.10 or 0.12 service, it'd be to node 4 so maybe keep that around longer than EOL?

I'm totally fine with that. I love using the es6 features and reducing deps wherever possible, but there is no compelling argument not to be conservative.

[wtgtybhertgeghgtwtg]

Will a version with #9 be released before this? It'd be nice if micromatch/micromatch#122 could get done without requiring a major version bump for micromatch.

[jonschlinkert]

Will a version with #9 be released before this? It'd be nice if micromatch/micromatch#122 could get done without requiring a major version bump for micromatch.

I agree, but only if there are non-breaking changes.

[danez]

@wtgtybhertgeghgtwtg micromatch/micromatch#122 is a breaking change I think, as snapdragon was also updated to a new breaking version. The core apia should not break (match, createRegex, parse, etc), but also compilers and parsers are exposed and this definitely will not seamlessly work as they will require the latest snapdragon version. It is also just a number :)

[jimmywarting]

+1 for dropping support for eol version and only targeting LTS version (meaning v6+)