Browser-compat-data: What should be the minimum listed version of nodejs?

[gilmoreorless]

This is split off from the discussion on #6618. Specifically this comment:

I also have an annoyance with 0.1.100 being the first version listed in the BCD files. I believe it's because console.log was added in that version (ref), but many features were in Node from earlier than that. It mostly annoys me just because of how it displays on MDN ;)

For context, version 0.1.100 was added in #3160, where there's also a discussion about Node versions. Since it's the earliest version listed, any other feature that was in Node from the beginning (i.e. inherited from whatever was in V8 at the time) has also been marked as 0.1.100 in BCD. (Often added by me, as part of #6249)

There are a couple of problems with this approach:

1. It's not really accurate, because plenty of V8-inherited features predate 0.1.100. But it's also not entirely clear which version _should_ be the minimum. The 0.1 series was already very experimental, and https://node.green only starts collecting data at 0.10. (See also @ddbeck's comment at https://github.com/mdn/browser-compat-data/pull/3160#issuecomment-486184341)
2. It has visual display problems on MDN. The version string is wider than the table cell containing it, as shown in the screenshot above.

One suggestion in #6618 was to use ≤0.1.100 as a range, but I feel that will only exacerbate the display issue. (I also thought it was a goal to reduce how many ranged versions were in the data.)

I'm willing to update the data files to match whatever we decide, but I want to be sure we've agreed on the version. Suggestions welcome.

[ddbeck]

Thank you for opening this, @gilmoreorless! I spent a bit of time thinking about this problem and I have some thoughts on it now which might help us solve the problem. If you don't want any background and want to skip ahead to the useful stuff, read the first and last sections. 😄

≤0.1.100 is a bad idea

First, I don't know what I was thinking by suggesting ≤0.1.100. The first version of _any_ browser or engine in our data set is implicitly "this version or some earlier version." We know, for example, that some Firefox features predate Firefox 1.0, but we don't use Firefox ≤1. This was a bad idea on my part and we shouldn't do it.

Pragmatism is probably still a good idea

My original argument in favor of recording pre-1.0 releases of Node.js still feels pretty good (and I don't feel that way about a lot of early BCD decisions). In summary, I said that restricting ourselves to 1.0-and-later releases of browsers was a pragmatic choice because we couldn't reliably get data for browsers before 1.0. But Node doesn't suffer from this problem as acutely as browsers.

Node's history, being relatively recent, is remarkably well-documented and access to historic versions is pretty good (for instance, nodenv will at least _try_ to build Node 0.1.14, though it fails on my machine—this may just be a macOS thing). It's plausible that one might be able to test _any_ documented release of Node.js, if you're sufficiently motivated. This suggests that if these two conditions are met, you could include it as a version in BCD:

1. the release is formally documented by Node.js in the long table of releases — in other words, that Node.js itself recognizes it as one of its releases
2. the release can be installed and run to test some feature

Plausible versions to be the "first" Node.js release in BCD

That said, Node.js _does_ favor some releases over others and we probably ought to respect that, even though it doesn't have a proper 1.0.0. While reading about old releases of Node, I came across this fascinating thread from the Node.js mailing list, which appears to capture the birth of Node's practice of privileging even-numbered releases over odd-numbered releases, with v0.2.0. This doesn't appear to be formally documented until v0.4.0, however.

So taking it all together, it seems like there's a few plausible choices for a first-release, from most recent to least recent:

• v0.12.0 — The convergence of io.js and Node.js and an LTS release.
• v0.10.0 — The oldest release acknowledged by the Node.js Release Working Group. It appears to be the first formal LTS release. My impression is that this is about when Node started to get genuinely popular, too, but I'm not sure about that.
• v0.4.0 — The first stable release documented as such at the time of release. This looks 1.0.0-ish, while being slightly older.
• v0.2.0 — The first stable release, though that was an informal commitment made in a mailing list thread _after_ it was released.
• v0.1.100 — The current value, which feels pretty arbitrary, to be honest.
• v0.1.14 — The first release listed on the Node.js site.

There's other points between (particularly, the even-numbered releases between v0.4.0 and v0.10.0), but this is pretty much it.

More questions

So we're back to the chief problem with v0.1.100 laid out by @gilmoreorless: it's not really accurate, because V8-inherited features predate 0.1.100 (the length problem isn't really _BCD's_ problem though I think it's also contributing to the appearance of precision we don't actually record).

To actually resolve this—to pick a version—I think we need to answer a couple questions:

• Are very early versions of Node.js actually testable? Could instructions be written to install Node.js v0.1.14 and test feature data on a contemporary computer? If yes, then we could probably go with it. If not (or if it's sufficiently painful to do it) then…
• Does any other version stand out as a more natural starting point than any other? Does any version have the appearance of marking the end of Node.js-as-an-experiment and the beginning of Node.js-as-a-production-tool?

@gilmoreorless, I'd really like your take on these questions. I feel like you're a lot closer to the audience of Node.js devs and might have a better read on this than I do (as a Node.js dilettante).

[gilmoreorless]

That's a wonderful amount of detail, @ddbeck, thanks for putting the effort into that research.

To answer your questions...

Are very early versions of Node.js actually testable? Could instructions be written to install Node.js v0.1.14 and test feature data on a contemporary computer?

It's a real mixed bag, in my experience. I'm also on macOS and the main trouble in installing very early Node.js versions for me is the need to compile old versions of V8. With a tiny bit of tweaking I've managed to get some early versions compiled for testing, but it's not a consistent range.

During my work on BCD I've tried to compile the following versions, with mixed results. (✅ = compiled without issue; ⚙️ = compiled after tweaks; ❌ = couldn't compile)

• ❌ 0.1.14
• ❌ 0.1.33
• ❌ 0.1.90
• ⚙️ 0.1.100
• ⚙️ 0.1.101
• ❌ 0.2.0
• ❌ 0.3.0
• ⚙️ 0.4.0
• ⚙️ 0.6.0
• ❌ 0.7.0
• ❌ 0.8.0
• ✅ 0.9.1
• ✅ 0.10.0
• ✅ 0.12.0

Does any other version stand out as a more natural starting point than any other? Does any version have the appearance of marking the end of Node.js-as-an-experiment and the beginning of Node.js-as-a-production-tool?

My gut feeling is 0.10. Partly because you pointed out it's the first LTS(-ish) release (and node.green starts tracking features there, making data verification easier). But partly also because I agree with you that it _feels_ that somewhere around 0.10 is when it started gaining traction. But that would bring an interesting problem, with several features explicitly listed in the API docs as being introduced before 0.10.

It might be worth actually posing this question to the Node.js Release Working Group. Their opinion would certainly have more weight than a random BCD contributor (me) with no connection to the maintenance of Node.js.

[ddbeck]

@gilmoreorless Thank you for checking that out. Great stuff!

It might be worth actually posing this question to the Node.js Release Working Group. Their opinion would certainly have more weight than a random BCD contributor (me) with no connection to the maintenance of Node.js.

Definitely! I was leaning that way myself, but seeing your suggestion made me more confident about it. I've opened https://github.com/nodejs/Release/issues/619 to get their take on the subject. I'll give them ample time to respond (I'm largely off next week anyway). Hopefully we can move forward on this, one way or another, the week after next.

[gilmoreorless]

Another data point I've just remembered, which comes back to your comment about testability of old versions. As part of #6249, a while ago I started looking at the missing function-related data for Node.js. I have a branch with most of the correct data values, but haven't made a PR for it yet due to some problems.

For each nodejs feature required, the first technique I use to determine versions is looking up the Chrome version in the BCD data, then match the V8 version against a release of Node.js. In most cases this is enough, as the Chrome version is either 1 (so the feature was in the very first version of Node.js), or the Chrome/V8 version is high enough that it matches the Node.js version listed on node.green.

For the function data, though, I hit problems:

1. Tracing the V8 version for some of the features indicated a "unstable" early version of Node.js — e.g. 0.3.0, 0.5.6, 0.7.0. Should I put the unstable versions into BCD, or round them up to the next stable version?
2. Some of the versions (both stable and unstable) were untestable on my local machine (as indicated in my previous comment). So I can't actually verify the correctness of the data.
3. In a small number of cases, the feature was present in Node.js well before the version indicated by the Chrome/V8 combo. This actually indicates incorrect Chrome versions in BCD, but again it's hard to test/verify these cases.

Resolving this "first listed version" problem will greatly help with case 1, and possibly case 2 depending on what the decision is.

[ddbeck]

OK, I've replied to the Node Release Working Group in https://github.com/nodejs/Release/issues/619 and closed that issue. I've concluded we should go ahead with choosing 0.10.x as our "first" version of Node.js.

I think the balance of indicators and practicality points toward this choice. It's not a perfect choice—Node has a rich prehistory of sorts—but it's testable (without heroic efforts) and has a sort of blessing to it. A little detail came out in https://github.com/nodejs/Release/issues/619: LTS status was applied retrospectively to 0.10.x. In some ways, this marks 0.10.x as the first release of a converged Node.js/io.js, if not Node.js alone.

There's a few consequences of this choice:

• We need to update the existing engine data for Node.js to drop the versions older than 0.10.x.
• We need to roll any existing data up into 0.10.x. If there's a value ≤0.10.x, then we should rewrite that value to 0.10.x.

That's not inconsequential work. In the mean time, I'd be happy to write up a data guideline (and release notes) indicating that this is the direction we're going and to use only ≥0.10.x values for new data.

Sound good, @gilmoreorless?

[gilmoreorless]

Thanks @ddbeck, that makes a lot of sense. It will certainly make updating the function and object data easier, and also make it easier for verification against node.green.

In the mean time, I'd be happy to write up a data guideline (and release notes) indicating that this is the direction we're going

Excellent. I'm sure there'll be questions in the future from people who notice inconsistencies between MDN and the Node.js API docs. Having a simple explanation to point them to will be very helpful.

[Elchi3]

OK, I've replied to the Node Release Working Group in nodejs/Release#619 and closed that issue. I've concluded we should go ahead with choosing 0.10.x as our "first" version of Node.js.

So cool to have feedback from that group!

I wonder: Do we need ".x"? I think it would be the first time BCD introduce such a version (BCD defines _real versions_, _ranged versions_ ("≥37"), and now it would add 0.10.x ("_ranged placeholder versions_"?).

[ddbeck]

@Elchi3 asks:

I wonder: Do we need ".x"? I think it would be the first time BCD introduce such a version (BCD defines _real versions_, _ranged versions_ ("≥37"), and now it would add 0.10.x ("_ranged placeholder versions_"?).

No, I think I we should use 0.10 in BCD, no placeholder or range indicator. I accidentally used the Node.js convention here because I had just finished writing to Node.js folks and I was trying to use their convention rather than ours.

[gilmoreorless]

No, I think I we should use 0.10 in BCD, no placeholder or range indicator.

On that note, I see that 0.10 and 0.12 are the only versions in browsers/nodejs.json that don't have the full semver number. Every version after 0.12 is listed as 4.0.0, 5.0.0, etc. Should 0.10 and 0.12 become 0.10.0 and 0.12.0 to match?

[ddbeck]

Yeah, they should be consistent. 👍

Here's a better task list for this whole thing:

• [ ] Write a data guideline to use only values ≥0.10.0 for new data
• [ ] Document initial versions for every engine (for BCD's consumers)
• [ ] Replace 0.10 and 0.12 with 0.10.0 and 0.12.0 respectively
• [ ] Bump support values <0.10.0 to 0.10.0
• [ ] Remove versions <0.10.0 from nodejs.json
• [ ] Update documentation of initial versions
• [ ] Drop the data guideline

[gilmoreorless]

That works for me. The only thing I question is dropping the data guideline at the end. Once all the other items are done, we're still going to need something to explain _why_ 0.10.0 is the earliest listed version. I'm thinking of a future case where someone notices that the Node.js docs say an API was introduced in, say, version 0.8.0 but BCD has it listed as 0.10.0.

[ddbeck]

That's a good point, @gilmoreorless. It occurs to me now that we should document, for consumers, what they should expect for the initial version of each browser, perhaps with the schema docs. That's probably a better place for that terminal bit of documentation to live anyway. I've updated my task list above accordingly.

[Elchi3]

I think this project is of a good size for me to get back to being more involved again, so I'm assigning this to myself.

[ddbeck]

@Elchi3 Thank you! Let me know if I can help at all and feel free to tag me for any reviews.

[Elchi3]

I've created PRs that aim to address these tasks:

• [x] Write a data guideline to use only values ≥0.10.0 for new data
• [x] Document initial versions for every engine (for BCD's consumers)
• [x] Replace 0.10 and 0.12 with 0.10.0 and 0.12.0 respectively
• [x] Bump support values <0.10.0 to 0.10.0
• [x] Update documentation of initial versions to make 0.10.0 the official initial version.

[Elchi3]

I think we can call this done now. Version 0.10.0 is now the official initial nodejs version in BCD, we've updated the compat data to take that into account, and we also improved BCD docs about what initial versions we have for all other browsers.

:tada: