Recently, I am working on a Node related project, which involves the processing of version number. Js upgrade is processed according to the size of version number. However, due to the extra one digit, js on line cannot be upgraded.

So you can only rewrite a version number comparison method that supports any number of digits.

By the way, let’s start with a semantic version number of literacy.

Why semantic version numbers?

In software management there is the valley of death known as “dependency hell,” and the bigger the system, the more packages you add, the more likely you are to find yourself at some point in the future in the depths of despair.

Releasing a suite of new releases on a highly dependent system can quickly become a nightmare.

If the dependencies are too high, you run the risk of version control being locked (every dependency suite must be changed to complete an upgrade).

If the dependencies are too loose, versioning chaos is unavoidable (assuming that more than a reasonable number of future compatible versions exist).

When the progress of your project is not easy or reliable because version dependencies are locked or version chaos, it means you are in dependency hell.

One solution to this problem is to constrain the configuration and growth of version numbers with a simple set of rules and conditions, known as semantic version numbers.

Semantic version number

The general semantic version number is usually defined as follows:

Js code:

Major_version_number. Minor_Version_Number[.revision_number [.build_number]] Specifies the major version number. Subversion number [. Modified version number [. Compiled version number]]Copy the code

Delimiters are generally used.

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, it 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.

And the version number is increasing, in the same place on the incremental, or a greater degree increasing, such as: ‘1.2.5.1’ = > ‘1.2.5.2’, ‘1.2.5.1’ = > ‘1.2.6.1’, ‘1.9.9.9’ = > ‘2.0.0.0 you are’.

For a more detailed version explanation, see semantic version 2.0.0 here.

Comparative method

This way we can do version number comparison, here is a method we use in the project, support any version number number comparison oh, such as 3 digits, 4 digits.

// 3 digits major_version_number. Minor_Version_Number[.revision_number] Specifies the major version number. Minor version number [. Modified version number] // 4 digits major_version_number.minor_version_number [.revision_number [.build_number]] Major version number. Subversion number [. Modified version number [. Compiled version number]]Copy the code

The comparison of any number of version digits is supported because version numbers are increasing, whereas the following method compares bits from left to right.

Js code:

/** * VersionCompare * @param {String} curVersion Current version * @param {String} supportVersion Comparison version * @return {Boolean} False The current version is less than the comparison version. Return true */ const versionCompare = (curVersion, supportVersion) => {if (! curVersion) { return false; } if (! supportVersion) { return false; If (curVersion === supportVersion) {return true; } const curArr = curVersion.split('.'); const supportArr = supportVersion.split('.'); for (let i = 0; i < curArr.length; I += 1) {if (+curArr[I]! == +supportArr[I]) {return curArr[I] > +supportArr[I]; } } return false; };Copy the code

It’s also easy to use:

Js code:

// 3 bits compare versionCompare('1.3.3', '1.2.5'); / / true versionCompare (' 1.1.3 ', '1.2.5); / / false versionCompare (' 1.2.5 ', '1.2.5); / / true / / four more versionCompare (' 1.2.5.1 ', '1.2.5.1'); / / true versionCompare (' 2 ', '1.2.3.5'); / / false versionCompare (' 1.2.3.6 ', '1.2.3.5'); / / true versionCompare (' 1.3.3.4 ', '1.2.3.5'); VersionCompare ('1.2.15.1', '1.2.5.1'); / / true versionCompare (' 1.2.15.1 ', '1.2.16.1'); // falseCopy the code

The important thing to note here is that according to my own business logic, the current version returns false if it is less than the comparison version and true if it is equal to the comparison version.

You can modify the code according to your business logic.

The last

Did not write technical article for a period of time 😂 really ashamed.

The next original article should be their year-end summary, this year’s year-end to come later than in previous years, the year-end summary in previous years are written in December next inquiry.

There is no way, December of this year is really very busy, has not arranged the first issue, 2020 year-end summary, will be written in January 2021 😂.

However, the year-end summary in previous years can be seen first:

  • End of 2019 for front End engineers – When you’re hard at work, but you’re unpredictable, how can you get rich
  • The Front End Engineer’s 2018 summary
  • The End of 2019 for Front-end Engineers – What a sweet story