[Reminder] Future git tags to be made on the `main` branch

[jengelh]

Build Version

-

Operating System Environment

• [ ] Microsoft Windows (32-bit)
• [ ] Microsoft Windows (64-bit)
• [ ] Mac OS X
• [ ] Linux (specify distribution and version below)

CPU Environment

• [ ] x86 (32-bit Intel/AMD)
• [ ] x86_64 (64-bit Intel/AMD)
• [ ] ARM (32-bit)
• [ ] ARM64 (64-bit; sometimes called AArch64)
• [ ] Other (RISC V, PPC...)

Game Modes Affected

• [ ] Single player
• [ ] Anarchy
• [ ] Hyper-Anarchy
• [ ] Robo-Anarchy
• [ ] Team Anarchy
• [ ] Capture the Flag
• [ ] Bounty
• [ ] Entropy
• [ ] Hoard
• [ ] Monsterball
• [ ] Cooperative

Game Environment

No response

Description

Observed:

Because the v1.5.0 tag is unreachable from the main branch, running git describe (or git describe --tags) on any recent commit leads nowhere. Please consider making future tags on main rather than release.

$ git describe origin/main
fatal: No tags can describe '76ddbefb094afb7b6ab938819d20d0a6ee966dea'.

Expected to see:

$ git tag vvv1.5.0 c01ef38b -m 'for demo'
$ git describe origin/main
vvv1.5.0-191-g76ddbefb

Regression Status

No response

Steps to Reproduce

No response

[Lgt2x]

I have to admit I did not consider that when branching out the release.

The way I conceive the workflow is:

• always make PRs target main so contributors don't have to wonder which branch to target
• when release time approaches, branch release from main
• continue merging new features to main
• manually backport only fix PRs to release
• when stable enough, create tag from release

Excuse my lack of git expertise there, but what do you think should be done differently? We're always open to improvements

[jengelh]

In the repository, I find commit 9cb836f9. It was about "33 commits too late" this time (should have been committed right after the branch-off), but other than that, that is the commit that could be tagged with something like v1.5.99—whichever numbering scheme pleases.

Alternatively, one could bring existing tags into scope with git co main; git merge v1.5.0 (possibly merge -s ours if no code join is desired).

Some projects also just do a freeze period (stop merging new features to main), so the antithesis to bullet point 3, which means they would not need v1.5.99 or explicit merging of a .0 tag since it will already be on main.

[Lgt2x]

Ok I get it, we'll do a 2 weeks feature freeze before the next release so we can do the tag directly on main, and make sure the very next commit updates the version number. Thanks for the heads-up!