gitea --version should have stable and clear output #3271

New Issue

GiteaMirror · 2025-11-02T05:06:13-06:00

GiteaMirror commented

2025-11-02 05:06:13 -06:00

Originally created by @xoxys on GitHub (Apr 30, 2019).

Gitea version (or commit ref): 1.8.0
Git version:
Operating system: Linux
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

For an automation purpose changing the version string from gitea --version from time to time is a nightmare because it will break any upgrade process which rely on current version. In some past releases the version information was "blown up" with some more build information (which makes it hard to parse the current version programmatically) and since the 1.8 release a parsable version number is completely gone which breaks my Ansible automation again.

Gitea version 34ba1c8 built with go1.12.4 : bindata, sqlite, sqlite_unlock_notify

Was the real version number removed accidentally or is it expected?

Originally created by @xoxys on GitHub (Apr 30, 2019). - Gitea version (or commit ref): 1.8.0 - Git version: - Operating system: Linux - Database (use `[x]`): - [X] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description For an automation purpose changing the version string from `gitea --version` from time to time is a nightmare because it will break any upgrade process which rely on current version. In some past releases the version information was "blown up" with some more build information (which makes it hard to parse the current version programmatically) and since the 1.8 release a parsable version number is completely gone which breaks my Ansible automation again. `Gitea version 34ba1c8 built with go1.12.4 : bindata, sqlite, sqlite_unlock_notify` Was the real version number removed accidentally or is it expected?

GiteaMirror added the type/enhancement label 2025-11-02 05:06:13 -06:00

GiteaMirror closed this issue

2025-11-02 05:06:13 -06:00

GiteaMirror commented

2025-11-02 05:06:13 -06:00

@HenrikBengtsson commented on GitHub (Apr 30, 2019):

I propose appending a numeric suffix d to x.y.z that clearly indicates it's a developer version, e.g. 1.8.0.9001. By making this d suffix very large, it'll also stand out.

The poor man's version would be to manually increment this, or at least keep it at 9000 to distinguish it from released versions. A better approach would be to set d = 9000 + number_of_commits_since(x.y.z). With the latter, separate branches will end up with the same x.y.z.d. To make that unique, one probably need to rely on the commit hash, but it can be clarified in parenthesis, e.g. 1.8.0.9015 (34ba1c8).

PS. Related to this: It's pretty hard for a non-savvy user to figure out what version https://try.gitea.io/ is running.

@HenrikBengtsson commented on GitHub (Apr 30, 2019): I propose appending a numeric suffix `d` to `x.y.z` that clearly indicates it's a developer version, e.g. 1.8.0.9001. By making this `d` suffix very large, it'll also stand out. The poor man's version would be to manually increment this, or at least keep it at `9000` to distinguish it from released versions. A better approach would be to set `d = 9000 + number_of_commits_since(x.y.z)`. With the latter, separate branches will end up with the same `x.y.z.d`. To make that unique, one probably need to rely on the commit hash, but it can be clarified in parenthesis, e.g. `1.8.0.9015 (34ba1c8)`. PS. Related to this: It's pretty hard for a non-savvy user to figure out what version https://try.gitea.io/ is running.

GiteaMirror commented

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

@mrsdizzie commented on GitHub (Apr 30, 2019):

I think the confusion here is that you haven't downloaded an actual release, but download something from the 1.8 folder here:

https://dl.gitea.io/gitea/

That is actually just the latest copy of the release/v1.8 branch which isn't an official release but the branch that official 1.8 releases are tagged from when released. The commit number shown in your sample output is from after 1.8.0 was released -- and matches the time as it would have been the last commit to that branch at the time of this issue.

If you download the actual 1.8.0 release at https://dl.gitea.io/gitea/1.8.0/ it will show:

Gitea version 1.8.0 built with go1.12.4 : bindata, sqlite, sqlite_unlock_notify

Admittedly it is confusing to just offer a link to all of those downloads with no text about it up front.

There is an entry in the FAQ here:

https://docs.gitea.io/en-us/faq/#difference-between-1-x-and-1-x-x-downloads

And the download guide references choosing a specific version, but there should probably be something to make that more clear in the downloads area itself (like a warning telling people not to use the 1.8 option unless they want a development/non-release version of 1.8).

As to the comment on try.gitea.io -- its should always running the latest version of master, as indicated by the commit number in the footer displayed on every page. It is never running a particular released version.

@mrsdizzie commented on GitHub (Apr 30, 2019): I think the confusion here is that you haven't downloaded an actual release, but download something from the 1.8 folder here: https://dl.gitea.io/gitea/ That is actually just the latest copy of the release/v1.8 branch which isn't an official release but the branch that official 1.8 releases are tagged from when released. The commit number shown in your sample output is from after 1.8.0 was released -- and matches the time as it would have been the last commit to that branch at the time of this issue. If you download the actual 1.8.0 release at https://dl.gitea.io/gitea/1.8.0/ it will show: ``` Gitea version 1.8.0 built with go1.12.4 : bindata, sqlite, sqlite_unlock_notify ``` Admittedly it is confusing to just offer a link to all of those downloads with no text about it up front. There is an entry in the FAQ here: https://docs.gitea.io/en-us/faq/#difference-between-1-x-and-1-x-x-downloads And the download guide references choosing a specific version, but there should probably be something to make that more clear in the downloads area itself (like a warning telling people not to use the 1.8 option unless they want a development/non-release version of 1.8). As to the comment on try.gitea.io -- its should always running the latest version of master, as indicated by the commit number in the footer displayed on every page. It is never running a particular released version.

GiteaMirror commented

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

@HenrikBengtsson commented on GitHub (Apr 30, 2019):

As to the comment on try.gitea.io -- its should always running the latest version of master, as indicated by the commit number in the footer displayed on every page. It is never running a particular released version.

I know that (after following various threads), but for any random user passing by that is not obvious (is it documented anywhere?). That adds unnecessary friction when it comes to troubleshooting/reporting etc. Since there are so many poorly-updated websites out there, there is a risk that this site gets incorrectly checked for the same. If the footer could link to the commit on GitHub that would make it much more clear, e.g.

Personally, I still think it would be very helpful if gitea --version for a development version would convey what x.y.z release it is based on.

@HenrikBengtsson commented on GitHub (Apr 30, 2019): > As to the comment on try.gitea.io -- its should always running the latest version of master, as indicated by the commit number in the footer displayed on every page. It is never running a particular released version. _I_ know that (after following various threads), but for any random user passing by that is not obvious (is it documented anywhere?). That adds unnecessary friction when it comes to troubleshooting/reporting etc. Since there are so many poorly-updated websites out there, there is a risk that this site gets incorrectly checked for the same. If the footer could link to the commit on GitHub that would make it much more clear, e.g. © Gitea Version: [eb8632b](https://github.com/go-gitea/gitea/commit/eb8632b20b8a3c3b51359860e12f2197cd03866e) Page: 0ms Template: 0ms Personally, I still think it would be very helpful if `gitea --version` for a development version would convey what `x.y.z` release it is based on.

GiteaMirror commented

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

@sapk commented on GitHub (May 1, 2019):

Currently we are following a logic similar to how go is versioned: https://golang.org/pkg/runtime/#Version

For information, the output of go version on master vs on release:

$ go version
go version devel +ba978f5fff Tue Apr 30 23:31:26 2019 +0000 linux/amd64
$ go version
go version go1.12.4 linux/amd64

@sapk commented on GitHub (May 1, 2019): Currently we are following a logic similar to how go is versioned: https://golang.org/pkg/runtime/#Version For information, the output of go version on master vs on release: ``` $ go version go version devel +ba978f5fff Tue Apr 30 23:31:26 2019 +0000 linux/amd64 $ go version go version go1.12.4 linux/amd64 ```

GiteaMirror commented

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

@zeripath commented on GitHub (May 1, 2019):

Hmm.

If we tag at the branch point for say 1.8 as 1.9-dev on master then I think git describe should give us better results for try. The only issue is that we would probably have to tag that after the first commit on master after the branch otherwise our first commits on the release branch will also likely change name too. We could actually do this for 1.9-dev without breaking the history.

@zeripath commented on GitHub (May 1, 2019): Hmm. If we tag at the branch point for say 1.8 as 1.9-dev on master then I think git describe should give us better results for try. The only issue is that we would probably have to tag that after the first commit on master after the branch otherwise our first commits on the release branch will also likely change name too. We could actually do this for 1.9-dev without breaking the history.

GiteaMirror commented

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

@sapk commented on GitHub (May 2, 2019):

I suggest to use the version reported by the module definition : https://github.com/go-gitea/gitea/issues/6812

I could make a PR to serve as an example but it could only be merge when we loose support for Go1.11 as it need a method introduce in Go1.12.

@sapk commented on GitHub (May 2, 2019): I suggest to use the version reported by the module definition : https://github.com/go-gitea/gitea/issues/6812 I could make a PR to serve as an example but it could only be merge when we loose support for Go1.11 as it need a method introduce in Go1.12.

GiteaMirror commented

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

@zeripath commented on GitHub (May 3, 2019):

Fixed by #6836 and its backport #6839

@zeripath commented on GitHub (May 3, 2019): Fixed by #6836 and its backport #6839

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3271