Should libuv upgrades be semver-minor? #443
Description
Refs: nodejs/node#24332
I've added the label periodically here is an example of an earlier version marked semver-minor
1.24.1 and 1.25.0 were both landed as patches as well
nodejs/node#25571
nodejs/node#25078
In general we have not landed these in semver-patch LTS releases, as such I think it would make sense to make it explicit that they are always semver-minor
thoughts?
/cc @cjihrig
Activity
Trott commentedon Jan 29, 2019
¯\(ツ)/¯
richardlau commentedon Jan 29, 2019
libuv follows semver, so I would expect the semverness of the upgrade to be related to the version being upgraded from/to.
MylesBorins commentedon Jan 29, 2019
@richardlau on one hand that seems like a reasonable alternative... on the other I think it is worth considering that a semver-patch change to libuv can be semver-major to Node.js if it breaks behavior
Trott commentedon Jan 29, 2019
To clarify my ¯\(ツ)/¯:
On the one hand, semver-minor is for new features and upgrading a dependency without adding a new feature is, uh, by definition not adding a new feature. So: patch!
On the other hand: There's no reason we can't decide to to make it semver-minor out of some abundance of caution?
Yet on the other other hand: What does that get us, exactly? Either way, semver-patch or semver-minor are not supposed to have breaking changes.
Yet back on some other hand somewhere: Psychologically, though, perhaps people think of "minor" bumps as a bigger change than patch, even if that's not strictly semver.
I guess if I had to make a decision: patch unless it introduces a new feature usable by an end user (which would include, say, someone compiling a native addon or whatever).
Trott commentedon Jan 29, 2019
A semver-patch change, by definition, should not do that.
If it does, it's because of a bug. But the same can be said for every semver-patch update.
Although libuv ones are bigger than others...
But that's why we have tests...
So...
¯\(ツ)/¯
MylesBorins commentedon Jan 29, 2019
From semver
I guess the question comes down to what our definition of "adding functionality is".
As we expose the libuv api (AFAIK) it would seem to make sense to a semver-minor bump to libuv is in turn a semver-minor bump in node.
Trott commentedon Jan 29, 2019
Responding to myself because it's that kind of evening: Ah, but then there's the ol' "one person's bugfix is another person's breaking behavior" problem.
But again, semver-minor should not include breaking behavior any more than semver-patch should...
¯\(ツ)/¯
Trott commentedon Jan 29, 2019
Could you elaborate on that?
MylesBorins commentedon Jan 29, 2019
Can people not use the libuv api when writing native modules?
https://nodejs.org/api/addons.html#addons_linking_to_node_js_own_dependencies
Also worth considering that we can have an LTS policy around libuv that is completely unrelated to how they land on master / current
richardlau commentedon Jan 29, 2019
I'd have no argument there.
We statically link libuv into the Node.js binary and provide the headers to addons in our headers tarball (as we do for V8 and OpenSSL and zlib).
Trott commentedon Jan 29, 2019
@MylesBorins wrote:
@richardlau wrote:
So that would suggest that the semver-ness of the upgrade in Node.js is the same as the semver-ness of the version bump in the dependency itself. And it also suggests that this is not libuv-specific but may also apply to
(at least) OpenSSLother dependencies.Sounds like we're (so far, at least) converging on that....
richardlau commentedon Jan 29, 2019
Except OpenSSL doesn't follow semver. (And neither does V8. No idea about zlib, which is the only other dependency we purposely reexport.)
Fishrock123 commentedon Jan 29, 2019
I see no reason why a regular libuv patch release upgrade that does not break node would be semver-minor, if that is what is being asked.
cjihrig commentedon Jan 29, 2019
We build libuv v1.x with Node master and then run the Node test suite before libuv releases now, so that shouldn't be an issue (not to say that things never slip through the cracks).
Since libuv follows semver, and is generally more stable across releases than other dependencies, I see no reason to make all libuv updates semver minor.
cjihrig commentedon Feb 6, 2019
@MylesBorins can this be closed?
MylesBorins commentedon Feb 11, 2019
@cjihrig I think we should document the consensus we have in here. I think the release wg meeting on thursday should result in an action item regarding where this should be documented
BridgeAR commentedon Feb 14, 2019
What about adding that information to https://github.com/nodejs/node/blob/master/doc/guides/contributing/pull-requests.md#dependencies?
cjihrig commentedon May 2, 2019
I'm transferring this to the release repo. The answer here appears to be "no" but the release working group is still discussing it.
mhdawson commentedon May 9, 2019
My thought is that libuv updates should match the semver stated by libuv (ie patch if patch, minor if minor), unless there is a specific reason that warrants something different.
BridgeAR commentedon Nov 19, 2019
I added it to the release agenda to discuss this in the next meeting.
I personally do not have a strong opinion but it's probably a good idea to idea to follow the libraries own semver version on our side to include it, if applicable. This can't be applied to dependencies that do not use semver and there might be exceptions where it makes sense to include an update in e.g., a patch release for security reasons or similar even though it's maybe semver-major for the dependency.
BethGriggs commentedon Dec 5, 2019
The consensus from #509 was that we will follow the semverness of libuv. If there's a patch upgrade of libuv, this can be included in a patch release of Node.js.