Should bundled npm semver force io.js semver?

[rvagg]

Continued discussion from #904 (comment)

Obviously I think it should because it's a very user-facing dependency and its behaviour is part of the bahviour of the thing you're installing when you're installing io.js.

WIll take this to tc-agenda if we can't land in a better place here.

Discuss.

[mikeal]

Does NPM 3.0 plan to break compatibility in some way?

[rvagg]

^^ ping @othiym23

I'm operating on the assumption that npm is actually following semver fwiw.

[chrisdickinson]

I'm +1 on assuming npm semver forces io.js semver, since (in module terms at least) we're just exposing their API through our "module."

[cjihrig]

+1. npm doesn't change the io.js APIs, but as previously mentioned, it is very user oriented. It can't hurt, and can only help prevent more issues from being opened here.

[Qard]

I think npm major should force io.js major, but I I'm not convinced npm minor should force io.js minor. I'm on the fence about it.

[brendanashworth]

I don't think it should force our hand in semver; npm is bundled with io.js to be easier on developers (because it's very hard to use it productively without npm), rather than npm being a part of the io.js library and runtime. A breaking change in NPM -- lets use npm login being renamed to npm signin as an example -- has nothing to do with io.js.

How would you plan on explaining that in the io.js changelog? That since a bundled library (note: not a dependency) broke backwards compatibility, io.js also breaks? A developer looks at the io.js changelog for breaking changes with io.js, and the npm changelog for changes with npm. Just because we bundle a popular library with the runtime doesn't mean we have to lock semver hands with them and release together in harmony.

[mikeal]

If npm ever dramatically broke compatibility (which will likely never happen) we'd have to consider not actually updating it :)

I want to make the point that the policy should be "changes in npm effect semver in io.js" and not "io.js will follow increments in npm semver" because I'm pretty sure that npm 3 will come out and not actually break backward compatibility but be a big enough release that they want to message it as a major version.

[rvagg]

The problem I have with not adopting a rigid rule about it is that somebody has to assess the impact and come up with a decision, which would be even more difficult to assess than a core feature.

As Isaac keeps on saying -- integers are cheap and we shouldn't be afraid to bump minor version and I like the approach being pushed by some members of this community, such as @domenic and @chrisdickinson (from memory), that we should err on the side of bumping minor if we're ever on the fence. Major bumping is a bit more tricky right no for historical reasons but that's another discussion. I'm actually mostly interested in minor for npm->io.js.

@brendanashworth as I said in #904, I don't think you can decouple the two, it's a rare situation to have node without npm (although we do occasionally see this in enterprise deployments), and it's even somewhat idiomatic to run Node/io.js programs via npm with npm start etc. If we shipped something that broke npm start in 1.9.1 then we'd surely be messing with users' assumptions about what semver means for functionality stability. Even a feature addition, like npm start affording some new syntax. Imagine if an end-user application like Ghost had to list in its instructions that you had to install "at least io.js 1.9.1" before you could start it with npm start--that's surely an obvious violation of semver for users.

[domenic]

I think the "npm login being renamed to npm signin" example gets to the crux of the issue. Do the people voting for tying these things together actually think that should cause a major version bump?

[rvagg]

@domenic perhaps, but, I think in the case of an npm major version bump I'd vote for holding it off while we make the most of the opportunity to bump major by adding more breakages in it that we want, like the util.isObject() patch (or whatever that was).

I'd be happy to limit it to only impacting io.js minor bumps though if that helps at all with clarity because that's the kind of situation we are actually facing every few weeks now.

[brendanashworth]

@rvagg It isn't so much about not decoupling them, rather so much that our semver is ours and shouldn't be ruled by a library we bundle into the source. Also, I'd say there is a big difference between "installing at least io.js 1.9.x" vs "running at least npm 3.x (bundled with io.js 1.9.0+ and node 0.12+)"; a bundled library != installing the io.js version with that specific library version. It isn't as if running a specific io.js version forces you to run the npm version bundled with it, and vice versa (disregarding very old versions).

I'd be up for a minor bump in semver when npm goes for a major bump, because it shouldn't be necessarily ignored by developers that the bump happened, but it shouldn't cause the "oh, major semver, what broke? should we stay on major x instead?..."

[mikeal]

@rvagg Good point, I think that we can assume the minor/patch increments in npm are in line with io.js' definition of the same. People only seem to have reservations about major.

[domenic]

I mean I have reservations about minor as well but it's also not that big a deal if we release a minor that in Domenic's opinion should have been a patch, so I'm not going to go to the plate for that position.

[mikeal]

We bump minor so often all on our own that I'm not worried about any particular dependency forcing it.

[rvagg]

@brendanashworth that logic doesn't hold if you apply it consistently across the project -- what is "ours" is actually pretty small, the files in src/ lib/ and doc/ with the majority of the code that makes up what we know as io.js coming from dependencies, most notably V8 and libuv but also OpenSSL, c-ares, http_parser and I'm asserting npm is the same in this regard even if it doesn't end up in the binary. A breaking change in V8 will force a major version bump on us, a feature addition in V8 will (probably) force a minor version bump on us. OpenSSL is going to have the same impact and it's not even necessarily compiled in to the binary we distribute, it could be a floating external dependency that changes depending on what your distribution installs (in the case of Linux distros that ship according to their archaic packaging rules). The collection of things we distribute in our downloads makes up "io.js" and npm is one of those, it just happens to be the most easily interchangable part of that--but in the majority of cases I expect it to remain the same version that you get when io.js was originally installed.

[brendanashworth]

@rvagg yeah, but I wouldn't say io.js dependencies and what depends on io.js should be treated equally. V8 feature additions are mutually part of io.js because the software is written with C++ bindings into it, can't compile without it; npm is a userland-ish module that we bundle for ease of use. That's where I'd like to draw the line between where semver should be in accordance and where it shouldn't.

npm changes just don't have to do with io.js semver really at all. Just because it is included in the tarball doesn't change that because it doesn't break io.js backwards compatibility, it breaks npm backwards compatibility.

[aredridel]

I do appreciate the distinction of 'bundled' vs 'depended on'. That does seem like a reasonable way to present things, so bumping npm wouldn't bump the io.js major; conversely, if the entire package is in scope, then that.

(This would be similar to a wholly subsumed dependency major bump not bumping major of a depending package, but one that's exposed by it should.)

Kind of a tough call and I think mostly boils down to where you draw the line as to what's in scope for semver.

[chrisdickinson]

Do we count the CLI we expose as part of our public API? I.e., if someone downstream is writing bash scripts for a version of io.js at a given major version, can they rely on all of the flags / exposed executables remaining the same for the duration of the major version?

My feeling is that the CLI we expose is part of our public API as a package, and since we expose both node and npm as a part of that interface, we should track major version changes in npm as well. The nuance is that npm could have breaking changes that are aren't part of their CLI, and those wouldn't incur a bump on our behalf, but ... it's safer to err towards bumping the major.

[othiym23]

1. npm's roadmap exists more or less independently of Node.js or io.js's. npm does follow semver, and it observes a "follow a regular release cadence, but only release things when they're ready" release process.
2. npm historically has not supported, and is not planning on supporting, any kind of LTS release series. The team is small and our backlog long, so we will patch bugs in new releases, but I am not interested in backporting patches or devoting resources to supporting multiple release series outside the bounds of semver-major transition periods.
3. As the person most directly responsible for coördinating support for npm, it is in my interests to always have Node.js and io.js users running the newest version of npm, because it is the version that I have certified to be closest to fit for everyday use.

I leave to the TC to decide io.js's versioning policy, but I will take a dim view of any solution that conflicts with any of the above. My personal opinion is that it doesn't make sense to couple io.js's version to npm's, and this is why I periodically make noises about wishing that npm and Node.js / io.js were bundled separately.

Do we count the CLI we expose as part of our public API?

Even (long) before I joined the npm team, I didn't see the two linked in that way, no.

[Fishrock123]

Do we count the CLI we expose as part of our public API?

I don't think so. It's not like npm is documented in our API docs or anything.

[aredridel]

Agreed.

[sam-github]

I agree with @Fishrock123, npm interface is not documented.

@piscisaureus at one time was wondering if node could ship with a "npm core", something that was only sufficient to bootstrap to npm, or perhaps that supported only one command: install

npm does lots of things, it would be nice to cut it free of node.

And since no io.js/node code will ever fail to run after npm is updated, I don't see how a major npm release can be considered a major for io.js. I can see the other argument, but I don't think its a useful bump of major. Usually you bump major because you expect some incompatibility.

[Fishrock123]

Should this be tc-agenda?

[othiym23]

If this does make it onto the TC agenda, I request that either myself or @isaacs be a part of the discussion, to represent npm's interests.

[rvagg]

It would be premature to take this to the TC but I'd like to keep this open for the time being as we'll likely enter a scenario where the question comes up again and we need to reengage. Also, Forrest's comments about LTS for npm are interesting and feed into the io.js discussion on the topic too for reasons similar to what prompted this discussion in the first place.