What counts as the first production release of Node.js?

[ddbeck]

Summary

MDN's browser compatability data project (BCD) wants to represent details of Node.js's version history, but we're not sure how or whether to record Node.js's history before Node v4.0.0. What version should we treat as Node.js's initial production-ready release?

(If this is a bad place for this question, my apologies. I'd welcome any advice about where else to take the question.)

Who's asking?

I'm a maintainer of MDN Web Docs's @mdn/browser-compat-data project. To help Web developers, we record the compatibility of thousands of Web platform features across several browsers and engines that implement them. The data is used to generate compatibility tables on MDN and is one source of data for caniuse. This data appears in millions of page views monthly.

Where possible, we record the most significant version number that introduced (or removed) a feature, starting with a browser's first stable releases. Some of our data includes Node.js, particularly JavaScript language features and some Web APIs.

What do v0.x version numbers mean?

We're not sure what the pre-v4.0.0 Node.js version numbers mean exactly and we were hoping the Release Working Group might be able to guide us. We want to know: which, if any, pre-io.js fork version numbers indicate a stable, production-ready release?

I did quite a bit of reading and investigating on my own which you can read about in mdn/browser-compat-data#6861 (comment) but I wasn't able to come to a conclusion. We know that even-numbered releases were privileged over odd-numbered releases and that v0.10 and v0.12 had an LTS status, but we're not certain whether v0.10, v0.12, or some earlier even-numbered version is a reasonable "first" stable release of Node.js.

I also reviewed the docs in this repo and searched the issues for anything that might've suggested an answer to this question, but I didn't find anything.

What is this for?

BCD's usual practice is to record significant, stable releases (with respect to the vendor's versioning scheme—browsers don't do semver, sadly, but if they did, our data would probably be equivalent to allowing major and minor releases only) and to treat a browser's history as beginning with its first stable release. For example, even though we know certain features predate Firefox 1.0, we record those features as having been first added in Firefox 1.

We think that adopting a similar practice for Node.js (e.g., treating every feature introduced in a v0.x releases as if it were introduced in v4.0.0) would mislead developers about Node.js's maturity. But we also don't want to reach too far back into Node.js's history and imply to developers that very old versions were stable and well-supported, when there is evidence that was not the case (and we're a little bit lazy and don't want to test many difficult-to-compile versions).

Thank you

We also figured that the hard-working people that make Node.js would have an opinion on the matter and who better to ask than the Release Working Group. Thank you for any assistance you can offer on this question.

[richardlau]

What do v0.x version numbers mean?

We're not sure what the pre-v4.0.0 Node.js version numbers mean exactly and we were hoping the Release Working Group might be able to guide us. We want to know: which, if any, pre-io.js fork version numbers indicate a stable, production-ready release?

I did quite a bit of reading and investigating on my own which you can read about in mdn/browser-compat-data#6861 (comment) but I wasn't able to come to a conclusion. We know that even-numbered releases were privileged over odd-numbered releases and that v0.10 and v0.12 had an LTS status, but we're not certain whether v0.10, v0.12, or some earlier even-numbered version is a reasonable "first" stable release of Node.js.

I also reviewed the docs in this repo and searched the issues for anything that might've suggested an answer to this question, but I didn't find anything.

👋. That's a tough question to answer. I first got involved with Node.js around Node.js 0.10.x and back then the notion of even numbers being stable and odd unstable existed (e.g. https://github.com/nodejs/node-v0.x-archive/wiki/FAQ/6e127cdfb1981a30cd34cb991395de383fc54460#what-is-the-versioning-scheme from the wiki of the original Node.js repository).

LTS status was retrospectively applied to 0.10.x and 0.12.x when Node.js and the io.js fork converged and was done because those two versions were widely in use at the time (see #7). Prior to convergence there wasn't, as far as I know, any formalization of "production-ready" -- I think today we'd generally apply the term "production-ready" to the even numbered LTS releases (but note that the even releases only gain LTS status six months six months into their release cycle).

It's probably okay to list 0.10.x and 0.12.x. Anything earlier than that is before my time and probably for most of the rest of the current WG members.

[ljharb]

I don't know what evidence you're referring to that older versions of node weren't stable or well-supported ("LTS" is not a requirement of anything being "well-supported"); the project was certainly less mature back then, but I'd say the first version that you really need to pay attention to is 0.6, since that's the first "stable" version that shipped with npm included.

My understanding of pre-io.js version number meanings is that odd 0.x versions were "unstable", and even ones were "stable".

[ddbeck]

Thank you very much for the background you've given me, @richardlau and @ljharb.

This has been really helpful. For example, there are some subtleties here (like the way even releases don't start with LTS status) that I wasn't previously familiar with.

You've helped me narrow the range of choices for the browser compat data project. I still have a bit of thinking to do, but I'm confident now that we won't communicate something seriously misleading to BCD's consumers, including MDN readers, even if we have to make a somewhat arbitrary cutoff.

One clarification before I close this up:

I don't know what evidence you're referring to that older versions of node weren't stable or well-supported ("LTS" is not a requirement of anything being "well-supported")

My apologies, @ljharb. I made a mistake during rewrites of my original post. What I meant and failed to articulate was that older versions of Node had some looseness about their status. For example, 0.2.x wasn't originally released as "stable"; it was a decision made later, as evinced by this mailing list thread. Looking back, it's difficult to judge what these things meant at the time, especially compared to the thoroughness of Node's process and communications today.

Again, thanks for your help on this question!