Golang Program Version Management

This is a creation in Article, where the information may have evolved or changed.

Overview

Versioning is primarily used to track the version of a running program so that it can manage the running version of the online service and avoid confusion among versions of the service program. The usual practice here is to embed the version mark in the program, The version number will also correspond to the tag or release version on Git. Thus, there is a more comprehensive description of the online service change. A version naming method based on the GNU style is described here.

1 version number naming format

The major version number. Child version number [. fix version number [. Build version number]] major_version_number.minor_version_number[. revision_number[. Build_number]] Example: 1.2.1, 2.0, 5.0.0 build-13124

• Major

Assemblies with the same name but different major version numbers are not interchangeable. This applies, for example, to a large number of overrides for products that do not allow for backward compatibility.

• Minor

If the name of two assemblies is the same as the major version number, and the minor version number is different, this indicates a significant increase, but it takes care of backward compatibility. This applies, for example, to a revision of the product or to a new version that is completely backwards compatible.

• Build

The differences in the build number represent a recompilation of the same source. This is appropriate for changing the processor, platform, or compiler situation.

• Revision

Assemblies that have the same name, major version number, and minor version number but different revision numbers should be fully interchangeable. This applies to fixing security vulnerabilities in previously released assemblies.

Subsequent versions of an assembly that differ only by build or revision numbers are considered to be previous versions of the hotfix (Hotfix) update.

2. Version number Management policy

1). At the beginning of the project version, the version number can be either 0.1 or 0.1.0, or 1.0 or 1.0.0.

2). When the project is in a local modification or bug fix, the major version number and the child version number are unchanged, the revision number plus 1;

3). When the project on the original basis to add some functions, the main version number is unchanged, the sub-version number plus 1, the fixed version number is reset to 0, so it can be ignored;

4). When the project has undergone significant changes or local corrections accumulate more, and the overall change of the project, the main version number plus 1;

5). In addition, the compiled version number is usually generated automatically by the compiler during the compilation process, we only define its format and do not control it artificially.

3. Embedding the version information into the project

For each service, create a new version of the package for versioning and manually change the version number in the compilation script. This version number must correspond to the version number one by one on Gitlab. When you execute the binary and enter the-v parameter, the version number of the program is printed, and the program is run without any parameters.

4. Example

Example See Https://github.com/g4zhuj/ver ...
Using the build script to compile a program with commit information, you need to modify the parameters in the build script according to the program.

The results of the implementation are as follows:

./example-v
version:0.0.1
Git commit:de07491
Go Version:go version go1.6.2 linux/amd64
Build time:2017-05-11 16:20:27

Reference

https://golang.org/cmd/link/