Write fixed versions #433

New Issue

GiteaMirror · 2025-11-02T03:23:19-06:00

GiteaMirror commented

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

Originally created by @tboerger on GitHub (Mar 7, 2017).

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

Originally created by @tboerger on GitHub (Mar 7, 2017). Currently we are generating the version, that ends quite often in confusion so we should skip that and write the versions statically.

GiteaMirror added the type/enhancement issue/stale labels 2025-11-02 03:23:19 -06:00

GiteaMirror closed this issue

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

GiteaMirror commented

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

@lunny commented on GitHub (Mar 9, 2017):

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

@lunny commented on GitHub (Mar 9, 2017): Git hash is very useful to find the problem. Fixed version cannot help us on that.

GiteaMirror commented

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

@appleboy commented on GitHub (Mar 9, 2017):

agree with @lunny.

@appleboy commented on GitHub (Mar 9, 2017): agree with @lunny.

GiteaMirror commented

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

@tboerger commented on GitHub (Mar 9, 2017):

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.

@tboerger commented on GitHub (Mar 9, 2017): 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`.

GiteaMirror commented

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

@strk commented on GitHub (Mar 11, 2017):

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 ?

@strk commented on GitHub (Mar 11, 2017): 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 ?

GiteaMirror commented

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

@laplix commented on GitHub (Mar 13, 2017):

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.

@laplix commented on GitHub (Mar 13, 2017): 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.

GiteaMirror commented

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

@stblassitude commented on GitHub (Jun 28, 2017):

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

@stblassitude commented on GitHub (Jun 28, 2017): 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

GiteaMirror commented

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

@lafriks commented on GitHub (Jun 28, 2017):

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

@lafriks commented on GitHub (Jun 28, 2017): I think it should be just tag when release version and version+hash when built from master

GiteaMirror commented

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

@stale[bot] commented on GitHub (Feb 14, 2019):

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.

@stale[bot] commented on GitHub (Feb 14, 2019): 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.

GiteaMirror referenced this issue

2025-11-02 11:45:18 -06:00

[PR #441] [MERGED] Provide button to delete merged pull request #15382

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#433