-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
blog: add Farewell to Node.js v5, Preparing for v7 post #879
Conversation
|
||
Every 6 months, we plan to release a new _major_ version of Node.js. The version is _major_ in the [semver](http://semver.org/) sense in that we hold back breaking changes on our master branch until the 6 month point where we can release them together in a batch. The creation of these new release lines occur during April and October each year. Even version numbers happen to come in the April release while odd version numbers are in the October release. | ||
|
||
Each major version of Node.js has an active life of 6 months in what we are now calling "Current". During this period we ship most of the active work that goes in to the Node.js codebase except for some items that we reserve for the next major release. Node.js version 5 was first released in October last year, so its "Current" period ended in April this year. At the end of this 6 month period, something different happens for odd and even versioned release lines. The even versions turn in to LTS (Long-term Support) and receive another 30 months of life; this happened for version 4 in October last year and will happen for version 6 in October this year. The odd versions, however, don't get this extended life. Instead, as a transitionary measure, we provide another 2 months of support where we'll ensure that important fixes make it into that release line. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rvagg have you seen nodejs/Release#128?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I hadn't, thanks for the link but see note there I just added.
Nice! really like the gif! |
1. Stability | ||
2. Progress | ||
|
||
The io.js diversion was useful for many reasons, including the opportunity we had to lean into this "progress" thing. We learned that there is a necessary trade-off between "stability" and the rapid iteration of the platform. Some of it was manageable but much was unavoidable. Breaking the entire C++ add-on ecosystem each time we upgraded V8 turned out to be quite painful for the Node.js package ecosystem. This is due to the heavy reliance on compiled native components in Node.js userland and the V8 project not having to be too concerned with the breakage and pain caused by the constant [API](wikipedia API) and [ABI](wikipedia ABI) churn since its primary consumer is Chromium. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it necessary to continue to sling mud at V8 here, especially given the recent history and the amount of energy myself and folks from V8 have been putting into better supporting Node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i agree, this part sounds a bit too harsh and personally biased :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I didn't intend this as mud slinging. It's an objective observation based on a lot of history and accurately reflects the state we were in during io.js, even if things have improved lately. I'll adjust and ping you both when I have an update.
Updated the post with feedback, put the "LTS" acronym expansion up front and adjusted the V8 API/ABI language to not suggest blame. @ofrobots @Fene can you please check that language in the latest commit 1041f52 and sign-off? Happy to adjust more if you feel there's still a lingering negative suggestion there. |
For simplicity, here's the new text:
|
@rvagg i feel that now it's neutral enough 👍 |
Looks good! |
general LGTM to this. is there a scheduled time to merge? |
It was published to https://nodesource.com/blog/farewell-to-node-js-v5-preparing-for-v7/, which seems a bit confusing for a PR made to nodejs/nodejs.org. |
This is a pretty strange way of merging |
Intended as a cross-post on both blogs, they have different audiences and nodejs.org is likely to have broader reach anyway. Cross-post note will be added to the nodesource.com version now with this merged. |
One minor correction: you have the v4 LTS expiration as October 2018, when it should be April 2018. v6 LTS will expire April 2019. |
thanks for picking that up @jasnell, fixed! |
LGTM. |
@nodejs/lts @nodejs/ctc @nodejs/website as per a commitment I made at an LTS meeting a while back, I was supposed to have this post up just after v5 went EOL but it was never quite completed and posted. Now we're in the in-between limbo-land so I've tried to reframe it as a v5-to-v7 story. It's basically taking the opportunity to do a refresher on the LTS scheduled.
I'd like some feedback from y'all about (a) whether this post makes enough sense to post now (I obviously think it does but the content has floating between my devices and in my head for a couple of months!) and (b) the content itself.
It's got the simplified animated LTS GIF that I prepared for the LTS README rewrite which attempts to communicate the very basics of the LTS plan in one image.