If you haven’t been closely following Node.js lately, it might surprise you to hear that the community just released versions 4.2.0 (LTS) and 5.0.0 (Stable). This is surprising because in July–just 4 months ago as I write this–the latest stable version of Node.js was 0.12.7. Needless to say, this may seem confusing for a project that had been slowly increasing its version numbers from 0.10.x to 0.12.x until recently.
Earlier this year, a significant portion of the primary Node.js developers forked the project and created a new project, named io.js. Forking is when the code from one project is used to start a new, separate project. It is perfectly legal, and not uncommon, in open source projects like this. In this case, the developers left Node.js over disagreements of project ownership, governance, and release cycles, among other things. io.js quickly released a number of improvements and seemed to have a lot of momentum, while Node.js appeared stagnant by comparison. The community that had been built around Node.js was left confused, unsure of which project to support and unsure of what this fracture would do to the community, as it looked like io.js and Node.js were quickly diverging.
Throughout early- to mid-2015 there were rumblings surrounding a possible merge of Node.js and io.js. The Node Foundation was formed so that the project was no longer owned by one entity, and a Technical Steering Committee was proposed along with new methods of governance and release planning. Ultimately, the io.js team voted to re-join Node.js under the new organization. In the time since the merge, io.js had been following a different style of software versioning, and they had grown from version 1.x to 3.x. Following the merge, the io.js code was brought back into Node.js, and version 4 marked the completion of the two teams coming back together.
So what does this mean for developers who are building apps on Node.js? There are 3 key takeaways:
Improved Documentation
As Node.js grew rapidly over the past few years, the project developers have had a hard time keeping up with documentation. This can make it difficult for developers who are new to the platform and want to dive in. Under the new structure, there are clear outlines and goals surrounding the improvement and continued development of project documentation. This is a big step in helping Node.js grow into a mature project.
Semantic Versioning
Node.js now follows semantic versioning in the numbering of its releases. To put it simply, this ensures that the number given to each release portrays the type of release it is. That means releases can be easily identified as simple patch fixes, minor releases, or major, breaking releases. For example, version 4.0 marks a major release. It’s likely that these changes could break an app when upgrading from 3.x. On the other hand, 4.2.1 will only feature bug fixes and will be backwards compatible with 4.2.0. This makes life easier for developers because they can reliably estimate the work involved to upgrade a system. Check out the Semantic Versioning website for more details about this specification.
Long Term Support
The biggest and most exciting change (in my opinion) to Node.js is the long term support (LTS) strategy. There will now be specific, stable releases for Node.js that will be marked as LTS, which means they will have an extended and predictable support lifecycle in which they will receive upgrades. Node.js as a project will continue to move quickly and release frequent improvements, but the LTS versions will be carried along for a mandated time period during which they will receive necessary updates. Every 12 months, a new major LTS version will be released, with each of them being supported for 18 months. This means that companies using Node.js can commit to using an LTS version and will receive necessary updates. Meanwhile, active Node.js developers and organizations that are using Node.js on less critical apps, plus those who simply want the cutting-edge versions, will still be able to follow along with a frequent release cycle. This new strategy effectively makes it easier for managers of large projects to commit to using Node.js while not affecting the active developers and users. The NodeSource team put together a great blog post with more details about the long term support strategy.
What are your thoughts on the new changes to Node.js? Have you upgraded your apps to version 4.x or 5.x? I’d love to hear about your experiences in the comments section below.
