What is the difference between LTS and Current in Node.js

This article will introduce to you the difference between LTS and Current in Node.js. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to everyone.

On October 18, 2016, Node.js v6 LTS (Boron) was released. This is also the first time since Node.js started the LTS release plan that two active LTS (v4 and v6). This series of articles will describe a series of changes brought about by Node.js v6 LTS. This article mainly focuses on LTS. If the reader is still unfamiliar with the release process of Node.js LTS, you can read this article first, otherwise you can skip reading the next article about Node.js Core changes.

Related recommendations: "nodejs Tutorial"

Node.js LTS Plan

Node.js core After the merger of Node.js and io.js, in order to ensure a stable and orderly release and allow developers to reasonably arrange upgrades, LTS (Long Term Support ) to plan the release cycle. The first LTS version was v4, released in October 2015.

Under this plan, the version of Node.js is equivalent to a snapshot of the master branch that has been stabilized at a specific time. When the time is up, the stable parts of the master branch will be integrated and a new version will be released. Therefore The release of Node.js is based on the passage of time, and the version jumps on the premise of ensuring close compatibility, rather than on the number of compatibility and new features. This also explains why the version of Node.js seems to jump. So fast (not "Ah, we have saved so many big moves, we can release a new version!" but "Ah, it's time to release a new version in April. Let's go through the big moves we have saved to see what is stable enough. Added in, although these tricks may not be that big...").

It is worth mentioning that the current Evergreen browser/mainstream JavaScript engine/ECMAScript standard/C standard also adopts similar principles, taking the time span as the benchmark, and intercepting stable features from the backbone for release .

Each LTS will have a code name. Take the element name from the periodic table, sort it alphabetically, and select the appropriate one. The code name of v4 is Argon (argon), and the code name of v6 is Boron (boron).

The version naming rules of Node.js follow Semantic Versioning (Semantic Versioning). The version number is divided into three parts. The first number (semver-major) increases, indicating incompatibility. changes; the second number (semver-minor) increases, indicating that there are new features that maintain compatibility; the third number (semver-patch) increases, indicating that there are changes while maintaining compatibility and features unchanged, such as Bugs fixed or documentation improved. This naming rule has advantages and disadvantages, which will not be described here. However, some of its contradictions make some exceptions to the naming of Node.js. For example, even if a security update causes incompatibility, in order to be able to update to all major versions, it is still semver. -minor.

The life of an LTS

##LTS current: April to October of the first year

Currently, Node.js will branch off from master every April, collect enough stable features, and release a major even-numbered version (such as v6.0.0) as an alternative for the next LTS. During the 6-month period from April to October of that year, this even-numbered version is called "current" (for example, v6.0.0 "current"). After accepting feedback from the community, this version will fix bugs, add new features, continue to improve, and may also delete some improvements that have too great a compatibility impact. At this time, the minor version of this version will continue to increase. Developers can use this time to test their applications offline with this candidate LTS version, and report compatibility issues and bugs to Node.js developers.

LTS active: October of the first year to April of the third year

By October of that year, this even-numbered version will become LTS (such as v6.9.0 "LTS"), At this time it is also referred to as "active LTS". During the next 18 months of active use, this version will almost never have any incompatible changes, and other dependencies (such as v8) other than security-related OpenSSL will not undergo major updates. During this period, developers can upgrade online Node.js to this stable LTS version and iterate using the new features of Node.js.

LTS maintenance: April of the third year to April of the fourth year

After 18 months of active period, in April of the third year, this version will usher in the last 12 months of maintenance period. At this time, its updates will only include security updates and bug fixes. Since Node.js releases an LTS in October every year, a new active LTS will be born on 2/3 of the nodes during the active period of this version (currently when v4 LTS has 6 months left to be active, v6 The time point when LTS active is released). By the time its active period ends, developers have had 6 months to transition to the next active LTS. Even if the progress of developer updates is slow, there is still 12 months of maintenance time, so upgrade as soon as possible. After 12 months, this LTS will end its life and will no longer receive any updates. So, every even-numbered version, has a lifespan of 3 years.

How do Node.js application developers choose?

For Node.js application developers who pursue stability, they only need to follow up and upgrade online when a version becomes active LTS in October every year, that is, every 12 The major version is upgraded once a month, and each upgraded version has a lifespan of 18 to 12 months. You don't have to worry too much about compatibility issues when following up on minors and patches. The current recommendation is that it is best to complete the online upgrade within 12 months after an active LTS comes out (because the next active LTS will be released after 12 months). If you are behind schedule, you can compromise until 18 months, before the end of the active period of this LTS. If you still can't catch up, you must at least upgrade it before the end of this version's life within 30 months, otherwise there will be no security updates.

If you are worried about the compatibility problems encountered by direct upgrade, you can test and upgrade offline in advance when the even-numbered version comes out every April, and feedback the problems to the community (of course, if you don’t have time) There is no need to worry about this step), and continue to follow up, and upgrade to the online version in October. In this way, both online and offline majors are promoted once every 12 months, but the time points are different. Although there are more compatibility issues that need to be followed up offline, you can also have your compatibility needs taken care of by the community through feedback.

If you are keen on trying new features, or if you are an experimental project that is not used in a production environment, you can try the odd-numbered major versions released every October. Each odd-numbered version will only be maintained for 8 months, and there will be no compatibility guarantee like LTS, but Node.js developers will use this version to prepare for the next LTS, so it will have more bold attempts. For example, more frequent v8 updates (meaning more ECMAScript new feature implementations and performance optimizations).

Therefore, developers who are still using v4.x online can already prepare to upgrade to v6.x. If your online application is still using a version released before the LTS plan was launched, such as v0.12.x, it is best to upgrade to v4.x or above as soon as possible, because v0.12.x will not be available after December 2016. There will be no security updates, let alone earlier versions. The main reason is that OpenSSL vulnerabilities will not be fixed, and these applications will be exposed to various security risks. Once you upgrade to v4.

How does this correspond to the source code of Node.js?

First of all, the Github Repo of Node.js has a master branch, and most commits are submitted to this branch through PR. Depending on whether these commits change compatibility or introduce new features, they are labeled semver-major or semver-minor.

When LTS needs to be prepared before April every year, Node.js will take a new branch from the master branch. If this is v6, then this branch is called v6.x-staging. Later modifications related to this LTS/modifications intended to enter this LTS, such as bug fixes, etc., still submit PR to master, but you need to add a tag lts-watch-v6.x.

After being merged into master, these changes will be picked out by the person responsible for release and merged into v6.x-staging. When the first version of v6 is ready for release one day in April, the person responsible for the release will create a v6.x branch and merge the changes from v6.x-staging. From April to October, all modifications to v6, whether minor or patch, are still submitted to master first, and then selected and merged into v6.x-staging, and then entered into v6.x when the version is released.

In this way, master always retains the latest changes. Other version-related branches are microcosms of mixing the commits selected from the master and suitable for release. v6.x-staging retains v6.x LTS-related modifications, and v6.x retains the version of each v6 release. . Except for the person responsible for handling the branch, other developers will not touch these version-related branches.

For more programming related knowledge, please visit: Programming Video! !

The above is the detailed content of What is the difference between LTS and Current in Node.js. For more information, please follow other related articles on the PHP Chinese website!