Bump __version__ to 0.20.4

[Kludex]

• Version 0.20.4 #1709 was missing the change on the __version__.

I've done a lot of releases already, and I made this mistake.

Suggestions for this to not happen again:

1. Create a bump script that will bump the version on __version__ and create an entry on the changelog.
2. Create a job on the pipeline when we have a release PR.
3. Have each PR with the changelog entry already, and the release PR just the change on the __version__.
4. Pay more attention.
5. ?

On this specific case, I'll have to delete the tag, and recreate it? I'm not sure I have rights to delete the tag... Or manual publish by @tomchristie...

[tomchristie]

Ah yeah one of those. 😌 No big deal.

Shall we figure out what needs fixing first, and discuss if there’s anything we want to do differently as a separate step?

Should we just roll a 0.20.5 release, as the path of least resistence?

[florimondmanca]

If I’m correct there’s no 0.20.4 yet on PyPI. I had this case on personal projects before. We could:

• Merge this PR
• Delete the 0.20.4 tag locally: git tag -d 0.20.4
• Create it again: git tag 0.20.4
• git push —-force —-tags

Only works if master is not protected for admins, I believe…

This should trigger the release pipeline again, which runs on tags. The release page on GitHub will update automatically with the new tag target.

[Kludex]

Just for reference, otherwise things get lost over time...

Thanks @florimondmanca 🙏

[Kludex]

Just for the record, what we have done:

• @Kludex deleted the GitHub 0.20.4 release.
• @tomchristie deleted the 0.20.4 git tag through the UI.
• @Kludex created another GitHub 0.20.4 release.
• Tag was created from the GitHub 0.20.4 release.

[adriangb]

Apologies folks, I take blame in this. Can we can check the tag against the __version__ in the publish workflow? I can send a PR.

[Kludex]

We do check the tag on the publish workflow. That's why it was not published on PyPI.

I take blame in this.

Let's share this. 😅

[tomchristie]

@adriangb - Not at all. It's a team effort.

Good to discover that resolving an incorrect GitHub release really is just a case of "delete the release, delete the tag". So I'm not too invested in if we want to put in place extra guards against this or not.

Also, I don't think the publish workflow is where we need checks. That did exactly what we want and failed, because the versioning was wrong.

One nice easy change we could make is to have the lint script compare the top version in the CHANGELOG with the package __version__. That wouldn't deal with also ensuring the git tag also matches, but it'd make sure we get the two code changes always in sync. We could make the CHANGELOG versions as eg. 0.20.4dev while we're in development, and 0.20.4 on a release PR. That check would have failed our release PR, and blocked us being able to merge it.