Recently, Github’s 10th anniversary has been widely reported on wechat. However, in my work, I was surprised to find that many colleagues have no idea about beta and RC in the version number. When using NPM install package@next, they are not clear about the meaning of next. So I decided to write an article about Semver(the semantic version), which was drafted by Github.

The actual case

First, let’s take a look at the last 5 months of React release logs from nPMjs.com, one of the most popular front-end frameworks.

From the above figure, it is not difficult to draw several conclusions:

  • The software version consists of three characters, such as X.Y.Z
  • The version is strictly incremental, here: 16.2.0 -> 16.3.0 -> 16.3.1
  • Alpha, RC, and other prior releases are available for major releases
  • Modified versions such as alpha and RC can be followed by the number of times and meta information

The React release did a pretty good job. The release felt very clear and rigorous. This is thanks to the Semver(semantic version) specification. So, in what context does Semver appear? What problem does it solve? Here I want to introduce you to the concept of “dependent hell”.

Rely on the hell

In layman’s terms, dependency hell is when a developer installs a software package only to find that it also relies on other packages of different versions. As the system becomes more and more complex and relies on more and more software packages, the system may face the risk of version control being locked.

As a result, Github drafted a guiding, unified version number representation rule called Semantic Versioning. This rule specifies how version numbers are represented, how they are added, how they are compared, and what different version numbers mean.

Official website: semver.org/ Chinese version: semver.org/lang/zh-CN/

Here is a screenshot of the React dependency diagram that follows the Semver specification.

As you can see, Semver compliant package dependencies are very clear, with no recurring dependencies, dependency conflicts, and other common problems.

Version format

Version format: Major version number. The second version number. The increment rule is as follows:

  • Major: When you make incompatible API changes,
  • Minor: When you make a backward-compatible Feature addition, which can be interpreted as a Feature version,
  • Patch: When you make a backward-compatible issue fix, it can be understood as a Bug fix version.

The prior version number and version build information can be added to the major version number. Second version number. Revision number “is followed as an extension.

First version

When releasing a large version or core Feature that is not 100% functional. This is when you need to release an advance release. Common early releases include: beta, grayscale, and RC. The Semver specification uses alpha, beta, rc(formerly known as GAMA) to denote upcoming releases. What they mean is:

  • Alpha: internal version
  • Beta: public beta version
  • Rc: Release candiate, the candidate for the official version

For example: 1.0.0 – alpha. 0, 1.0.0 – alpha. 1, 1.0.0 – beta. 0, 1.0.0 – rc. 0, 1.0. P – rc. 1 version, etc. Alpha, beta, and RC require the number of times.

Release guidelines

Here are some useful rules:

  • The standard version number must be in the XYZ format, and X, Y, and Z must be non-negative integers. Zero padding before the number is prohibited. The version release must be strictly incremented. For example, 1.9.1 -> 1.10.0 -> 1.11.0.
  • After a software version is released, any changes must be released in the new version.
  • The 1.0.0 version number is used to define the public API. Release 1.0.0 when your software is released to a formal environment or has a stable API.
  • Version priority refers to how different versions compare in order. When determining the priority level, you must divide the version number into the major version number, the minor version number, the revision number, and the earlier version number for comparison.

NPM package depends on

When NPM install package -s is executed to install a tripartite package, NPM first installs the latest version of the package and then writes the package name and version number to the package.json file.

For example, when installing React via NPM:

{
  "dependencies": {
    "react": "~ 16.2.0"}}Copy the code

The package dependency of a project can be expressed in three ways (assuming the current version is 16.2.0):

  • Compatible modules Latest patch versions: ~16.2.0, 16.2.x, and 16.2
  • Compatibility module newly released minor version, patch version: ^16.2.0, 16.x, 16
  • Compatible module major version, minor version, patch version: *, X

NPM package release

Usually when we publish a package to the NPM repository, we modify package.json to a version and then execute the NPM publish command. Manually changing the version number is based on your familiarity with the Semver specification, or it can lead to version confusion. NPM takes this into account and provides commands to better comply with the Semver specification:

  • Upgrade patch version: NPM Version Patch
  • Upgrade minor version: NPM Version Minor
  • Major version: NPM Version Major

When NPM publish is performed, the current version is first published to NPM Registry, and then the value of dist-tags. Latest is updated to the new version.

When NPM publish –tag=next is executed, the current version is first published to NPM Registry and the value of dist-tags.next is updated to the new version. Next could be named in any meaningful way (e.g. V1.x, v2.x, etc.)

OK, now you know what next stands for when NPM install package@next!

IVWEB Technology Weekly shocked online, pay attention to the public number: IVWEB community, weekly timing push quality articles.

  • Collection of weekly articles: weekly
  • Team open source project: Feflow