Automatically generated version on build

[lunny]

I think we can learn Golang's version management.

On master, all the version numbers will be gave on build and the version number is the commit hash. Since the hash is too long, we can use the first 7 characters. i.e. tip+2b445c7

On release branch, all the version number will be gave on build and the version number is branch name plus git hash. i.e. 1.0+2b445c7

For a tag version i.e. 1.0.0, the version number could be static and we can give it a special number not a git hash.

So that, when a user report an issue, we can know the question is from which version quickly.

[makhov]

In our project we use git describe --tag and build with

$ go build -ldflags "-w -s -X main.Version=${VERSION}"

[strk]

+1 for using `git describe` (maybe `git describe --always` in case tags are not present). NOTE: at the moment, tags are not present...

[lunny]

It seems it's a good idea

[lunny]

So we should create a make.bash & make.bat instead a Makefile? @tboerger

[tboerger]

We can accomplish that with the Makefile as well, I would just add the version part to it.

[lunny]

Makefile ask people to install make system first. Many gophers come from Ruby and Python not C or C++. And since build Gitea is so easy that it's no need a Makefile. Or we can move it to 1.1.0?

[strk]

+1 to move it to 1.1.0 BTW, we still need version embedded in a .go file for "go get" to end up with a proper version printed in pages, no ?

[tboerger]

Go get should simply have 0.0.0+master

[tboerger]

But most gophers also got build-essentials installed which also includes make

[strk]

On Mon, Nov 07, 2016 at 06:31:56AM -0800, Thomas Boerger wrote:

Go get should simply have 0.0.0+master

How about 1.0.0-dev, and incremented after release ?

[tboerger]

Because we should always provide valid version numbers.

[strk]

is 1.0.0-dev invalid ?