Create version tag after commiting to changelog

[h7x4]

Hello!

I'm currently trying to package this for nixpkgs, and I'd like to create a piece of metadata that contains the url to the changelog entry with the specific version. The current changelog contains dates in the headers, so unless we keep a list of dates upstream, it will be impossible to recreate a URL based on only the version.

Instead of removing the dates from the headers in the changelog, I think it makes more sense to reorder the steps in CI to create a commit with changelog entries before it creates the version tag. It might make sense to do this for other distros as well, so that they can receive a more useful changelog when downloading the source tarball for a specific version of the repository.

[bwoodsend]

Just to clarify, you have for example the version 2024.4 and you need to generate the URL https://.../CHANGELOG.rst#20244-2024-04-13 but you can't because you don't know the date? And you want the git tag to happen after the release xxx commit presumably so that git show $tag gives you something you can use instead?

[bwoodsend]

Would just shoving the date out of the title and onto the line below not be easier?

[h7x4]

I'd like to be able to link to https://github.com/pyinstaller/pyinstaller-hooks-contrib/blob/v2024.7/CHANGELOG.rst and have it show me the changelog for v2024.7 at the top of the file. The end goal is just to be able to link to the versioned release notes, so linking to a date-less header on master would be okay too.

Would just shoving the date out of the title and onto the line below not be easier?

Maybe? I don't think the alternative solution should be particularly hard either. As far as I know, it should just be a bit of reordering here, creating the "Release v$VERSION" commit first, followed by the tag and then the github release. As mentioned before, it would have the extra benefit of including the changelog entries in the source tarball.

https://github.com/pyinstaller/pyinstaller-hooks-contrib/blob/2d3b5666e40f287b5f45dfa0f386528c7a632e6e/.github/workflows/release.yml#L41-L54

[bwoodsend]

Ahh, that's how you intend to get the URL. I only mentioned the other option because I couldn't figure out how you were going to derive 20244-2024-04-13 even with the tag on the release commit. Makes sense now...

I'm pretty certain that the tag before the commit is an accident so I'd be making that change anyway.

[bwoodsend]

Oof, our release workflow is a mess!

Now that I look at it, the tag the commit before weirdness looks like an intentional workaround to trying to do the release and bump the version to the next one in one commit (@rokm mind if we ditch the practice of setting the version between releases to whatever we expect the next release version to be? I stopped doing that yonks ago with the main repository).

We are also getting two tags: An intentional vXXXX.X tag on the commit before the release and an accidental XXXX.X tag on the release commit presumably created implicitly by gh release.

[rokm]

@rokm mind if we ditch the practice of setting the version between releases to whatever we expect the next release version to be? I stopped doing that yonks ago with the main repository

Sure, go ahead.

I think the drawback of this is that pip install https://github.com/pyinstaller/pyinstaller-hooks-contrib/archive/refs/heads/master.zip will require a prior pip uninstall pyinstaller-hooks-contrib (because the versions will otherwise match), but I can live with that. (If nothing else, it will be consistent with main repository, where I've been bitten by this before...)