Automatically generated version on build about gitea

[strk]

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

[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 ;)

[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.

[makhov]

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

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

[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]

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.

[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