The premise

What is version? Semantic version control (SemVer for short) is a version control system that has been evolving over the past few years. With new plug-ins, plug-ins, extensions, and libraries being built every day, it’s a good thing to have a common approach to versioning software development projects to help us keep track of what’s happening.

The format of SemVer is X.Y.Z, where:

X stands for Major release

Y stands for Minor.

Z stands for Patch.

How does SemVer work?

SemVer is an easy way to determine the type of release you should release.

If you fix a bug or make some minor change, then this is classed as a patch, in which case you should upgrade Z.

If you implement new features in a backward compatible way, then you will upgrade Y because that is what is called a minor release.

On the other hand, if you implement something new that might break an existing API, you need to upgrade X because it is a Major release. For more information, see < More Tips > below.

start

Semantic version control is very important, of course, and getting a version update becomes a seemingly unimportant but very important thing. In our development process, or have you ever been in a situation like this?

  • Because version control concepts are vague or forgotten, you will either change the version of the application or forget to change the version completely after building it.
  • It is too troublesome to change the version after each build.

Based on this scenario, I developed the automatic version upgrade management tool auto-vers

Making: github.com/zerolty/aut…

Same library comparison

project npm-auto-version update-version auto-vers
git tag support Does not support support
Automatic updates Does not support support support
Prompt update Does not support Does not support support

Manual vs. Auto-vers

Here is what we need to manually change (the premise needs to know what to change, and do not forget to change!)

Here is the way auto-vers is used.

Features owned

  • Update major, Minor, Patch, Premajor, PreMinor, Prepatch or prerelease
  • Prompts for selection at update time
  • Git tag is supported
  • Automatically recommend the appropriate version based on git commit information

use

There are two import modes: Node and Cli.

npm i auto-vers -g 
Copy the code

Cli

Basic mode

cat package.json
{
    ...
    "version": "1.0.0"
    ...
}
Copy the code
auto-vers -i
Copy the code
cat package.json { ... "Version" : "" 1.0.1... }Copy the code

Confirm the model

auto-vers -i -c
Copy the code

Alert mode

auto-vers -t
Copy the code

If you don’t want to update, you can use CTRL + C to stop it.

Prompt and Git combined mode

With this option, when you select a version, you will automatically commit a commit and tag it.

auto-vers -t -g 
Copy the code

Change mode directly

Auto - vers 1.2.0Copy the code

or

Auto - vers - v 1.2.0Copy the code

options

Auto-vers 1.0.0 Auto Update Version for your application Usage: auto-vers [options] <version> [[...]] Options -v --version <version> Can update version directly. -i --inc --increment [<level>] Increment a version by the specified level. Level can be one of: major, minor, patch, premajor, preminor , prepatch or prerelease. Default level is 'patch'. Only one version may be specified. -e --extra [<value>] This is for prerelease extra data Such as 'beta','alpha' -c --confirm Do not update the version directly, you can confirm. This is a safe mode. -t --tip Provide choice to you. If you don't know how to update you can choose this option. -g --git Help you make a tag.(Make you have a git repo)Copy the code

Best practices

It is a good option to run this command at the same time as you finish packing your project.

Basic way

"script": {
    "build": "babel ./src --out-dir ./dist",
    "tip": "npm run build && auto-vers -t",
    "version": "npm run build && auto-vers -t -g",
}
Copy the code

After you’ve written a package command, following auto-vers-t will give you an indication of how many versions you need to upgrade to, which will give you some indication. Help you better determine what version you need to upgrade to. Json -> git commit -> git tag -> git push Origin [tagname]

Intermediate way

"script": {
    "build": "babel ./src --out-dir ./dist",
    "patch": "npm run build && auto-vers -i -c",
    "minor": "npm run build && auto-vers -i minor -c",
    "major": "npm run build && auto-vers -i major -c",
    "beta": "npm run build && auto-vers -i prerelease -c",
}
Copy the code

This method is for those who are familiar with the pattern, and only need to execute the corresponding command every time they need to pack. (Add -c –confirm. This is a safe way to upgrade and will help you make sure the upgrade is correct, if it’s too much work for you, remove it.)

The high way

git-hooks

If you haven’t registered pre-commit or post-commit, move it directly to your.git/hooks directory

mv githook-*/*  .git/hooks/
Copy the code

If you have hooks locally, manually add hooks from the project to your hooks

cat githook-*/pre-commit >> .git/hooks/pre-commit
Copy the code

When you commit a commit, the selection screen will automatically pop up and you will upgrade the corresponding version. (Note: If you have a commit command in your program, use –no-verify to skip this hook, otherwise it will be looped)

For more information

Why SemVer

Because non-standard version numbers are basically meaningless. Upgrade 4.2 from 4.1.0? good Why is that? Why not five? Why not 4.1.1? Why not 4.11? Why not 4.1.0-aplha.0?

Strict guidelines help provide meaning for version numbers. For example, if you look at version 1.3.37, you will know that this is the first major release, but there are already three minor releases that bring new features. However, you’ll also notice that this is the 37th patch in this release, which means there are a lot of bugs (few or large) involved.

It also helps to manage dependencies, “babel-cli”: “~6.26.0”, we introduced babel-CLI, which is known as version 6.26.0. It will lock x and y, which is a conservative approach. According to the rules, the upgrade of Z will not lead to major API changes and the introduction of new features. But if Babel-CLI doesn’t follow SemVer and introduces disruptive changes when upgrading Z, it could make our application buggy or unusable. It is because of SemVer’s specification that we can safely lock X and Y, so that Z can automatically upgrade, because the upgrade of Z may fix some minor bugs or some detailed improvements, and we can fix the known bugs without breaking our application.

More skills

Now that you know what SemVer is and how to automatically update it, let’s talk about some considerations when updating it.

Began in 0.1.0 from

One thing to note when using SemVer is that it starts at 0.1.0, not 0.0.1 as we might expect. This makes sense, because instead of starting with a patch, we started with a set of features as the first draft of the project, hence version 0.1.0.

Prior to 1.0.0 it was just development

Whenever you’re building a new piece of software, there’s always that phase of confusion where you’re asking yourself: When should I release the first major release?

Here are some tips to help you answer this question: If your application is already in production or users depend on it, you should already be at 1.0.0. In addition, if you break the current API, this also means that you need to upgrade your major version number.

Otherwise, keep in mind that releases below 1.0.0 are based on the development boom and you’re focused on getting your features done. Before 1.0.0, you should not be afraid of any disruptive features, so that when 1.0.0 is reached, it will be stable.

About pre-release pre-realEase

Before you deploy a major release, you usually go through a lot of work that needs to be tested over and over again to make sure everything works.

With SemVer, you can define pre-releases by attaching identifiers to versions. For example, a pre-release of version 1.0.0 might be 1.0.0-alpha.1. Then, if another pre-release is needed, it will become 1.0.0-alpha.2, and so on.

conclusion

After the basic introduction above, if you are not using SemVer, there is no reason not to work on your next project (or current project?). Use it on. Not only does it help your version of the project make sense, but it also helps others who might use your project as a dependency. Having said all that, I hope you can develop projects in a more disciplined way that will not only help others, but also benefit yourself. Maybe the project I developed is not perfect, but the original intention is to improve the efficiency of everyone’s specification. There are bugs please point out more, there are functional problems also please speak candidly.

link

Blue autumn wind without shadow er

reference

Medium.com/fiverr-engi…

www.sitepoint.com/semantic-ve…

Pay more attention