Gitea: Write fixed versions

[tboerger]

Currently we are generating the version, that ends quite often in confusion so we should skip that and write the versions statically.

[lunny]

Git hash is very useful to find the problem. Fixed version cannot help us on that.

[appleboy]

agree with @lunny.

[tboerger]

We should just take the tag name + the last commit. This is something set by the CI. That's not so confusing like the crappy versioning that is currently used. I just say 1.0.0+388-g60db7ed5 instead of a proper version like 1.1.0+dev or 1.1.0+dev-60db7ed5 or 1.1.0+60db7ed5.

[strk]

Isn't the currently generated version already using tag name + last commit ? I see 1.1.0+10-ge2b2fd6e on try.gitea.io, why do you think it's bad ?

[laplix]

As a user, when I download and install a tag (release) version, I want to see that tag when I start the application.

A tag version does not change. So, if I file a bug against a tag version, you have all the necessary information.

When I look at my logs, I want to see the version I am running, not its hash tag. I don't want to come here trying to find the exact commit.

I am running a version, not a commit...

Thank you very much.

[stblassitude]

I'm the package maintainer for the FreeBSD package of Gitea. The FreeBSD port downloads the respective release as a tar from Github; git never enters the picture. Right now, building the release 1.1.2 makes gitea info gitea show a version 1.0.0+dev (also in the web pages), which is confusing to users of the package.

My Go knowledge is not sufficient to suggest an implementation, but releases should integrate the actual release version instead of a fallback.

See also https://github.com/stblassitude/gitea-port/issues/1

[lafriks]

I think it should be just tag when release version and version+hash when built from master

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.