What is the difference between lts and current in nodejs?

Difference: Current refers to the latest node version currently released, which contains the latest features, but will be unstable and will be updated, optimized or fixed from time to time; while LTS refers to long-term support The node version is the stable version, and the functions contained in it are stable.

The operating environment of this tutorial: windows7 system, nodejs version 12.19.0, DELL G3 computer.

Go to the nodejs official website to download https://nodejs.org. There are two versions, LTS and Current. what differences are there? Which one should I choose? Of course, if you know the difference, you will know which version to choose.

Summary of the difference between LTS and Current: In fact, one can tell from the version number that one is new and the other is old. Current is the latest version, and the latest features are all in it. It is just for you to try and test. If everyone uses it well and the function is stable, it will be released to the LTS version. So LTS is the stable version.

The following is the version plan of nodejs

Node.js LTS plan

Node.js core After the merger of Node.js and io.js, in order to ensure stable and orderly releases and allow developers to reasonably arrange upgrades, LTS (Long Term Support) began to be used 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, the version jump is based 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, April is here and it's time to release the new version. Let's go through the big moves we have saved and see if there are any that are stable enough to be added. Although it may These tricks are not that big..."). It is worth mentioning that the current evergreen browsers/mainstream JavaScript engines/ECMAScript standards/C standards also adopt 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. The version number is divided into three parts. The first number (semver-major) increases to indicate incompatible changes; the second number The 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, such as bug fixes or improvements. document. 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.

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 up 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, the 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.

[Recommended learning: "nodejs tutorial"]

The above is the detailed content of What is the difference between lts and current in nodejs?. For more information, please follow other related articles on the PHP Chinese website!