gitea --version should have stable and clear output

[xoxys]

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

[HenrikBengtsson]

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.

[mrsdizzie]

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.

[HenrikBengtsson]

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

[sapk]

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

[zeripath]

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.

[sapk]

I suggest to use the version reported by the module definition : #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.

[zeripath]

Fixed by #6836 and its backport #6839