Release version 2.0.4

[Eutropios]

• See if all tests, including integration, pass
• Get the release pull request approved by a CODEOWNER
• Squash merge the release pull request with message "Release <VERSION>"
• Tag with X.Y.Z, push tag on urllib3/urllib3 (not on your fork, update <REMOTE> accordingly)
  • Notice that the <VERSION> shouldn't have a v prefix (Use 1.26.6 instead of v.1.26.6)

  • git tag -s -a '<VERSION>' -m 'Release: <VERSION>'
    git push <REMOTE> --tags
    

• Execute the publish GitHub workflow. This requires a review from a maintainer.
• Ensure that all expected artifacts are added to the new GitHub release. Should
  be one .whl, one .tar.gz, and one multiple.intoto.jsonl. Update the GitHub
  release to have the content of the release's changelog.
• Announce on:
  • Twitter
  • Discord
  • OpenCollective
• Update Tidelift metadata
• If this was a 1.26.x release, add changelog to the main branch

[Eutropios]

Thanks for the feedback!

[rawlingsj]

Hi - we are packaging urllib in Wolfi and have some automation setup to track when projects create a release.

We merged a change just over an hour ago however when the release pipeline for packaging ran our expected commit check failed.

We've made an assumption wolfi-dev/os#3711 of what may have happened, however wanted to reach out to confirm if possible?

Are we correct that there was a 2.0.4 release but may have been deleted and recreated with a tag associated to a new commit sha?

If our assumption is wrong then we'll continue to investigate our side as to why we initially got an incorrect commit sha.

Congratulations on the 2.0.4 release!

[sethmlarson]

Hey @rawlingsj, your assumption is correct! We placed the 2.0.4 tag on the incorrect commit so moved it to the correct one before executing our deployment pipeline. Apologies for the confusion, appreciate you coming to clarify explicitly. 🙏

[rawlingsj]

Oh that's great to hear! Many thanks for confirming 😄