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 ?

[tboerger]

Yes

[strk]

According to which specification is `1.0.0-dev` invalid ? Should maybe be `1.0.0+dev` or something similar ?

[lunny]

go build on branch master: 1.0+dev
go build on branch v1.0: 1.0.0+dev
go build on tag v1.0.0: 1.0.0

make on branch master: 1.0+hash
make on branch v1.0: 1.0.0+hash
make on tag v1.0.0: 1.0.0

[strk]

@lunny that means never having the commit-hash !
I think commit-hash should always be there except for builds on tag

[tboerger]

These are my 2 cents, because we should always keep valid semver versions:

go build on branch master: 1.0.0+dev, 1.1.0+dev, 1.2.0+dev
go build on branch v1.0: 1.0.0+dev, 1.0.1+dev, 1.0.2+dev
go build on tag v1.0.0: 1.0.0+631c18a

make on branch master: 1.0.0+dev, 1.1.0+dev, 1.2.0+dev
make on branch v1.0: 1.0.0+631c18a, 1.0.1+631c18b, 1.0.2+631c18c
make on tag v1.0.0: 1.0.0+631c18a

These are also valid versions for most packages like rpm or deb.

Edit: Maybe we should even stick with make on branch master: 1.0.0+dev, 1.1.0+dev, 1.2.0+dev, otherwise we can not differentiate it anymore.

Edit: And maybe go build on tag v1.0.0: 1.0.0+631c18a won't work because we can not patch the commit into the tag code, so more like go build on tag v1.0.0: 1.0.0+dev ;)

[strk]

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

These are my 2 cents, because we should always keep valid semver versions:

go build on branch master: 1.0.0+dev, 1.1.0+dev, 1.2.0+dev
go build on branch v1.0: 1.0.0+dev, 1.0.1+dev, 1.0.2+dev
go build on tag v1.0.0: 1.0.0+631c18a

make on branch master: 1.0.0+631c18a, 1.1.0+631c18b, 1.2.0+631c18c
make on branch v1.0: 1.0.0+631c18a, 1.0.1+631c18b, 1.0.2+631c18c
make on tag v1.0.0: 1.0.0+631c18a

These are also valid versions for most packages like rpm or deb.

+1, it works for me.

[lunny]

go build on tag v1.0.0: 1.0.0+631c18a
make on tag v1.0.0: 1.0.0+631c18a

I think only 1.0.0 is ok for tags.

[strk]

@lunny that'd be even better but I'm afraid go build cannot possibly include the hash w/out changing a version file on each and every commit. make instead would extract it dynamically