fix: use correct tag when commit is tagged with both prerelease and release

[sbruens]

Add a Git config specification to make goreleaser find the latest tag for a specific release, following this advice.

When you run goreleaser on a non-rc tag, the corresponding commit will always have 2 tags (the vX.X.X-rcY and vX.X.X tags) and goreleaser seems to be picking the wrong one, which puts the -rc variant first. This prevents someone from checking out the vX.X.X tag and running goreleaser.

[sbruens]

Actually this only resolves the problem when there are multiple tags, but will not work if the vX.X.X tag does not yet exist, which would happen if you run this for a new release candidate. I need to think about this a bit more.

[sbruens]

Ok I changed the approach and updated the PR description accordingly.

[fortuna]

Why remove the -rc from the filename? Isn't it better to make it clear it's a release candidate?

[sbruens]

Then we can't simply promote an -rc by creating a new tag, as we've been doing.

If we want to go the route where we keep the -rc in the filename, we'd have to either:

1. Delete the existing assets, update the prerelease, and create new assets by running goreleaser again.
2. Delete the existing pre-release and create a new release with new assets by running goreleaser again.
3. Somehow change the name of all the assets and checksum file on the existing prerelease.

For 1 and 2 we run the risk of introducing (build environment) changes between the pre-release and the release that's published. Not sure how easy 3 is to automate, but it could be messy.

[fortuna]

I believe you are trying to simply upgrade the candidate binary. If that's what you want to do, can you confirm that the correct version (without the -rc) is being injected here:

outline-ss-server/cmd/outline-ss-server/main.go

Line 44 in d240aa1

var version = "dev"

. Otherwise you will need to figure out how to inject the version correctly, or rebuild like we used to.

For context, we didn't use to create a release for candidates, only set the tag. I think we created prereleases sometimes. Once confident about the candidate, the release was created. In that case you don't need all those steps you listed. vN-rc-M can be one prerelease and vn can be another. There was no need to edit releases.

[sbruens]

I'm okay with that approach. The less a developer needs to manually amend the release candidate, the better, so if we're rebuilding having separate GitHub releases is safer.

I can revert the file renaming part of this PR and update our process doc to avoid upgrading the candidates in the prerelease.