Automatically generated version on build #37

New Issue

GiteaMirror · 2025-11-02T03:05:14-06:00

GiteaMirror commented

2025-11-02 03:05:14 -06:00

Originally created by @lunny on GitHub (Nov 6, 2016).

Originally assigned to: @bkcsoft on GitHub.

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.

Originally created by @lunny on GitHub (Nov 6, 2016). Originally assigned to: @bkcsoft on GitHub. 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.

GiteaMirror added the type/enhancement topic/deployment labels 2025-11-02 03:05:14 -06:00

GiteaMirror closed this issue

2025-11-02 03:05:15 -06:00

GiteaMirror commented

2025-11-02 03:05:15 -06:00

@makhov commented on GitHub (Nov 6, 2016):

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

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

@makhov commented on GitHub (Nov 6, 2016): In our project we use `git describe --tag` and build with ``` $ go build -ldflags "-w -s -X main.Version=${VERSION}" ```

GiteaMirror commented

2025-11-02 03:05:16 -06:00

@strk commented on GitHub (Nov 6, 2016):

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

@strk commented on GitHub (Nov 6, 2016): +1 for using `git describe` (maybe `git describe --always` in case tags are not present). NOTE: at the moment, tags are not present...

GiteaMirror commented

2025-11-02 03:05:16 -06:00

@lunny commented on GitHub (Nov 6, 2016):

It seems it's a good idea

@lunny commented on GitHub (Nov 6, 2016): It seems it's a good idea

GiteaMirror commented

2025-11-02 03:05:16 -06:00

@lunny commented on GitHub (Nov 6, 2016):

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

@lunny commented on GitHub (Nov 6, 2016): So we should create a make.bash & make.bat instead a Makefile? @tboerger

GiteaMirror commented

2025-11-02 03:05:16 -06:00

@tboerger commented on GitHub (Nov 7, 2016):

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

@tboerger commented on GitHub (Nov 7, 2016): We can accomplish that with the Makefile as well, I would just add the version part to it.

GiteaMirror commented

2025-11-02 03:05:16 -06:00

@lunny commented on GitHub (Nov 7, 2016):

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?

@lunny commented on GitHub (Nov 7, 2016): 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?

GiteaMirror commented

2025-11-02 03:05:17 -06:00

@strk commented on GitHub (Nov 7, 2016):

+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 ?

@strk commented on GitHub (Nov 7, 2016): +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 ?

GiteaMirror commented

2025-11-02 03:05:17 -06:00

@tboerger commented on GitHub (Nov 7, 2016):

Go get should simply have 0.0.0+master

@tboerger commented on GitHub (Nov 7, 2016): Go get should simply have 0.0.0+master

GiteaMirror commented

2025-11-02 03:05:17 -06:00

@tboerger commented on GitHub (Nov 7, 2016):

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

@tboerger commented on GitHub (Nov 7, 2016): But most gophers also got build-essentials installed which also includes make

GiteaMirror commented

2025-11-02 03:05:17 -06:00

@strk commented on GitHub (Nov 7, 2016):

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 ?

@strk commented on GitHub (Nov 7, 2016): 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 ?

GiteaMirror commented

2025-11-02 03:05:18 -06:00

@tboerger commented on GitHub (Nov 7, 2016):

Because we should always provide valid version numbers.

@tboerger commented on GitHub (Nov 7, 2016): Because we should always provide valid version numbers.

GiteaMirror commented

2025-11-02 03:05:18 -06:00

@strk commented on GitHub (Nov 7, 2016):

is 1.0.0-dev invalid ?

@strk commented on GitHub (Nov 7, 2016): is `1.0.0-dev` invalid ?

GiteaMirror commented

2025-11-02 03:05:18 -06:00

@tboerger commented on GitHub (Nov 7, 2016):

Yes

@tboerger commented on GitHub (Nov 7, 2016): Yes

GiteaMirror commented

2025-11-02 03:05:19 -06:00

@strk commented on GitHub (Nov 7, 2016):

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

@strk commented on GitHub (Nov 7, 2016): According to which specification is `1.0.0-dev` invalid ? Should maybe be `1.0.0+dev` or something similar ?

GiteaMirror commented

2025-11-02 03:05:19 -06:00

@lunny commented on GitHub (Nov 7, 2016):

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

@lunny commented on GitHub (Nov 7, 2016): 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

GiteaMirror commented

2025-11-02 03:05:19 -06:00

@strk commented on GitHub (Nov 7, 2016):

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

@strk commented on GitHub (Nov 7, 2016): @lunny that means never having the commit-hash ! I think commit-hash should always be there _except_ for builds on tag

GiteaMirror commented

2025-11-02 03:05:20 -06:00

@tboerger commented on GitHub (Nov 7, 2016):

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

@tboerger commented on GitHub (Nov 7, 2016): 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` ;)

GiteaMirror commented

2025-11-02 03:05:21 -06:00

@strk commented on GitHub (Nov 7, 2016):

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 commented on GitHub (Nov 7, 2016): 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.

GiteaMirror commented

2025-11-02 03:05:22 -06:00

@lunny commented on GitHub (Nov 8, 2016):

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.

@lunny commented on GitHub (Nov 8, 2016): `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.

GiteaMirror commented

2025-11-02 03:05:23 -06:00

@strk commented on GitHub (Nov 8, 2016):

@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

@strk commented on GitHub (Nov 8, 2016): @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

GiteaMirror referenced this issue

2025-11-02 11:38:55 -06:00

[PR #37] [MERGED] Change import reference to match gitea instead of gogs #15103

GiteaMirror referenced this issue

2025-11-02 11:39:09 -06:00

[PR #49] [CLOSED] Ordering organizations and users by name #15113

Sign in to join this conversation.