Re-Tag pre-release correctly on production as latest release

[josias-r]

Hi!

I'm not sure what the thought process behind the current behaviour is, but for me I'm not sure why a master release to an existing pre-release won't mark the release on github as the latest release.

Semantic-release for NPM has that behaviour as I would expect.

To clarify what I mean:

1. Use this simple releaserc config (and this GH action)
2. Push a release-relevant commit to the next branch
3. Release CI will run and correctly publish a:
   • x.x.x@next NPM package
   • x.x.x GitHub release tagged as pre-release
4. Merge the next branch into master
5. Release CI will tag the existing x.x.x@next NPM package with @latest

But the GitHub release, will NOT be tagged as latest-release.

I would expect for the GitHub release to also be tagged similar to NPM.

[JasonLandbridge]

Same issue here, did you find a solution?

[gr2m]

I remember that there was a reason why we couldn't do this in the past, maybe an API was missing or not working correctly. If you could look into it and test if you can mark a pre-release on github as latest, that would be a great start. Once we verified that it's possible, we can work on a pull request to add that functionality

[brenden-ef]

It looks like this feature is now available in the API. I ran a pre-release

then merged to my primary release branch, this removed the pre-release status from the branch.

I think this should mean that per the github api, this can now be marked as latest per the make_latest argument since it's no longer a pre-release. https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28

Specifies whether this release should be set as the latest release for the repository. Drafts and prereleases cannot be set as latest. Defaults to true for newly published releases. legacy specifies that the latest release should be determined based on the release creation date and higher semantic version.