mdn
Remove patch version from NodeJS versions
What would you like to see added to BCD?
In #18737, the author commented that "12.6.0" is technically inaccurate because the feature was added in NodeJS 12.6.2. (NodeJS, if you're reading this, adding a feature in a patch version is against SemVer policies...) This got me thinking: why do we include patch versions for each NodeJS version? I think it would be better to simply remove the appended ".0" to the NodeJS versions.
How impactful do you think this enhancement will be?
I think that this will help reduce potential confusion with NodeJS versions. Additionally, this help reduce liability if a feature was added in a later patch version (which again, is against SemVer policies and shouldn't have happened in the first place).
Do you have anything more you want to share?
No response
Here's how the nodejs docs call their versions. Maybe we should switch to that?
I'm in favor of removing patch versions from NodeJS versions, but I would suggest to treat 12.6 as a short-hand for 12.6.0, so if a feature was added in 12.6.2, we should use 12.7 instead.
I don't think that 12.6.2 should become 12.7; I think it should remain 12.6.0. In the guidelines for choosing a version number, we state that patch version numbers are simply dropped.
But isn't this about backporting? https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/index.md#backported-releases says the opposite. Something implemented in Safari 4.1 gets set as Safari 5.0.
That section was written because Safari created a few releases where they backported almost all of the features from a newer version to older ones for compatibility with older macOS versions -- so they took Safari 5.0 and released it as 4.1 as well, containing nearly all the same versions. They did the same for Safari 8.0 to 6.2. Backported features, on the other hand, are generally okay for NodeJS since it does it so commonly and its versioning is non-sequential.
The part I'm referring to is in the summary of the choosing a version number section: "Likewise, if a feature was not available in Safari 10.1.1, but added in Safari 10.1.3, then the supported version is 10.1."
This came up in the BCD call today, as a candidate for version 6.
I'm opposed to silently removing patch versions, but would be OK with 22.13.x and the like. I think it's not great (it can imply that features shipped on a date earlier than they actually did), but tolerable.
If we make this change, then we should do two things in documentation:
-
Document that Node.js versions are fuzzy and that, strictly speaking, the supported-on date is potentially as late as the most-recent patch release for that minor release line (potentially multiple years later!), not the x.y.0 release date that we give the JSON.
-
Document an explicit data guideline for Node.js backports.
Specifically, that we have to represent backports as a sequence of adds and removes when they happen in even-year releases. That is, if something ships in Node.js 24.0.0 and gets backported to 22.?.0, then you'll have to represent that as:
- Version added 24.0.0
- Version added 22.?.0 and version removed 23.0.0
I'm opposed to introducing pseudo versions like 22.13.x, because I don't see any advantage over precise patch versions (in particular, they have the same length), and they don't have a specific release date.
As a compromise, could we agree on omitting the patch version if it is .0, and keep the patch version only for those few cases where it isn't .0 (because Node.js didn't adhere to semantic versioning)?
The BCD tables on MDN now omit trailing .0 by default to save horizontal space, but I'm still in favor of omitting these in the BCD browser release data as well, just like we already do for e.g. Safari 26.0 (recorded as "26" in BCD).
We discussed this in today's BCD meeting, and decided to close this as wontfix.