Gopkg: A convenient way to manage your go pakcage

In the process of using go, we sometimes introduce some third-party libraries to use, and the usual way is to use go get , but this way has a very serious problem, assuming that the third-party library updated the relevant interface, it is very likely that you will not be able to use, so we set a very good package management mechanism.

In reading the best practice of go language in the production environment, I introduced the SoundCloud Company's practice, directly check down the code of the third library, put it in the Vendor folder of project, or use GODEP.

Just now, I found a better way to manage the package gopkg. It allows the Go tool to check the specified version number library by agreeing to use a URL with a version number, although it is now only supported on GitHub's go repositories, but I think it's strong enough.

A very easy example, we get the YAML package for go by way of the following

go get gopkg.in/yaml.v1

In fact, the corresponding address of the YAML package is:

https://github.com/go-yaml/yaml

YAML.V1 indicates that the version number is V1, and on GitHub there is a corresponding V1 branch.

The URL format supported by gopkg is very easy:

gopkg.in/pkg.v3      → github.com/go-pkg/pkg (branch/tag v3, v3.N, or v3.N.M)gopkg.in/user/pkg.v3 → github.com/user/pkg   (branch/tag v3, v3.N, or v3.N.M)

we use V. N to define a version number and then create a branch with the same name on GitHub. GOPKG support (vmajor[. minor[. PATCH]] This type of version number mode, assuming that there are multiple major the same version number, such as v1,v1.0.1,v1.1.2, then gopkg will choose the highest level of v1.1.2 use, such as the following version number:

• V1
• v2.0
• v2.0.3
• v2.1.2
• V3
• v3.0

Then gopkg the appropriate choice of ways such as the following:

• PKG.V1-V1
• Pkg.v2-v2.1.2
• Pkg.v3-v3.0

GOPKG does not recommend the use of V0, which is the 0 version number.

Gopkg at the same time, a number of recommendations are listed, whether the major version number needs to be upgraded after the code is updated or not, some cases where the major version number must be upgraded:

• Delete or rename the exported interfaces, functions, variables, and so on, whatever.
• Add, delete, or rename a function to an interface
• Add a parameter to a function or interface
• Change the parameters of a function or interface or return value type
• Change the number of return values for a function or interface
• Change the structure body

In the case of a situation, there is no need to upgrade the major version number:

• Add an export interface, function or variable
• Renaming a function or interface's parameter name
• Change the structure body

The above mentioned the change structure, for example, I add a field to a struct, it may not be necessary to upgrade the major version number, but suppose to delete an export field of the struct, it must be upgraded. It is not necessary to upgrade anything that simply changes the non-exported fields inside the struct.

For more specific information, please see gopkg directly.

As you can see, Gopkg uses a very easy way to manage the version number of Go pakcage conveniently. So I also according to gourd painting scoop, to my log package made a V1 version number, you can directly go get gopkg.in/siddontang/go-log.v1/log .

Gopkg: A convenient way to manage your go pakcage