Gitea: Tags missing on master since v1.1.0

[silverwind]

I noticed that since v1.1.0, release tags are no longer picked up by git describe (and in turn show wrong in the interface footer). For example, from the current GitHub master:

console $ git clone [email protected]:go-gitea/gitea.git . $ git describe --tags v1.1.0-894-g1687aa59
What's weird is that the missing tags do show on git tag:

console $ git tag | tail -1 v1.3.2

Anyone know what's up?

[silverwind]

Looks like this cause is that master is no longer tagged since v1.1.0, meaning the tags only exist on branches:

````console
$ git log --graph --all --decorate | grep tag:
| * commit bdf18560110ac642c196054be38729760a4bbc39 (tag: v1.3.2, origin/release/v1.3)
| * commit 81fd8c8fb686621acfdd91a73ade75b44030ce18 (tag: v1.3.1)
| * commit 974cffead9b8e6bb554ea458a90aac8203907a55 (tag: v1.3.0)
| * commit 751f01936b5796fe77dbf8e9356cc5bd380914eb (tag: v1.3.0-rc2)
| * commit 4683e540ad504ca96346fff34f686ee2a1f2cd5c (tag: v1.3.0-rc1)
| * commit 09bd05732de61930c99509ee5a25816895f430a8 (tag: v1.2.3, origin/release/v1.2)
| * commit d81cf34e37657ca0dba28ff45389ee341d90deb0 (tag: v1.2.2)
| * commit 46bb1cf0262a38ffdbdf25bb3da3bf564ccdaff8 (tag: v1.2.1)
| * commit ed07d8a3081759ab078ece41340d4a84d30f83fd (tag: v1.2.0)
| * commit 03ff7687e02b86b956fffc74fb2ab66430cd96d1 (tag: v1.2.0-rc3)
| * commit fc0c6f48c7c7d3a476974a27cc9de79fa08a79e0 (tag: v1.2.0-rc2)
| * commit bbb0b8c17c0554c525c6e5c6cfb71aa62d0abb93 (tag: v1.2.0-rc1)
| * commit 34182c87ec50f647fc6f5b97ba201c3bd42f0728 (tag: v1.1.4, origin/release/v1.1)
| * commit 5bb20be8b2c88ec063a8ebb730d3ed4be9ad456d (tag: v1.1.3)
| * commit bbe6aa349ff0c87e5fefe3dfbc6e16c7c1cb2795 (tag: v1.1.2)
| * commit f9859a29913a4fddbdd9f67febef3553ddf8c98b (tag: v1.1.1)

• commit 1d652913425c5e296d60e6ee268a2c1f59a3379a (tag: v1.1.0)
  | * commit e2c8d6fcb2c4073ed5cf164d88e7b5d44d95943c (tag: v1.0.2)
  | * commit 155fb93b9b1cee976c852a0ae7540911630c18b8 (tag: v1.0.1)
• commit 6aacf4d2f09631359b99df562b4bf31dcef44ea3 (tag: v1.0.0)
• | commit 6bcff7828f117af8d51285ce3acba01a7e40a867 (tag: v0.9.99)
  ````

Would it be possible to tag master on each release too, so that this footer is updated when building from source?

[lafriks]

No we can not tag master as it is way ahead and there is already PRs merged for next major release

[silverwind]

I'd be fine with removing the version number and just showing the commit hash. I see that https://try.gitea.io already has such a version in the footer:

But when I build from the git source, I seem to always get the output of git describe --tags in my footer. I wonder if try.gitea.io is built differently, hmm.

[strk]

Commit has is part of the git-describe output (final part, after the "g").
In general, tagging before branching would fix this problem.
I think the procedure described in the documente added by PR https://github.com/go-gitea/gitea/pull/2609 (HOWTO_RELEASE) would give us that.

[lafriks]

At most we could tag RC1 on master but I don't see much point in that

[sapk]

If we want to put tag on master we should consider master has stable and use a develop branch (currently master branch) but that is not the same git flow than currently.

[silverwind]

Tag before branch would definitely work as the tag is also visible on the branch, see below example workflow:

```console
$ git init
$ git commit --allow-empty -m "first"
[master (root-commit) 8829b85] first
$ git tag v1.0.0 -m v1.0.0
$ git commit --allow-empty -m "second"
[master f6f310f] second
$ git describe
v1.0.0-1-gf6f310f
$ git branch branch
Branch 'branch' set up to track local branch 'master' by rebasing.
$ git checkout branch
Switched to branch 'branch'
Your branch is up to date with 'master'.
$ git describe
v1.0.0-1-gf6f310f

[sapk]

Just the rethinking of it as 1.5.0 release iscoming.

I agree with @silverwind we could also tag master before but it will work only for major release 1.5.0 (that could be enough to mark progress) but we could not add minor tag 1.5.1 to master as it will differ from branch release where it should be.

I propose another solution, couldn't we tag master as 1.5.0-dev and 1.6.0-dev after releasing 1.5.0 ?
This way we know that it is a dev version of 1.X and will be consistent with default tag used without make env. https://github.com/go-gitea/gitea/blob/master/main.go#L24

[lafriks]

Tagging master branch for 1.x.0 version would mean that it would be frozen for 2-3 weeks more after rc1 for new features while we get out stable version

[sapk]

Yes, that why I suggest 1.X.0-dev to show that it is a dev version as better alternative.

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

[lunny]

This is still a problem

[lafriks]

@lunny I think it is not as we now add 1.X.0-dev tags to master

[silverwind]

Yes, I think it is resolved. On master:

$ git describe
v1.7.0-dev-92-g6b0c2e9e3

[lunny]

The master should be v1.8.0-dev :)