Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump __version__ to 0.20.4 #1713

Merged
merged 1 commit into from Jun 28, 2022
Merged

Conversation

Kludex
Copy link
Sponsor Member

@Kludex Kludex commented Jun 28, 2022

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...

@Kludex Kludex requested review from a team and tomchristie Jun 28, 2022
@tomchristie
Copy link
Member

tomchristie commented Jun 28, 2022

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
Copy link
Member

florimondmanca commented Jun 28, 2022

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 Kludex merged commit 0b132ee into master Jun 28, 2022
4 checks passed
@Kludex Kludex deleted the release-0.20.4-this-cannot-happen branch Jun 28, 2022
@Kludex
Copy link
Sponsor Member Author

Kludex commented Jun 28, 2022

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

image

Thanks @florimondmanca 🙏

@Kludex
Copy link
Sponsor Member Author

Kludex commented Jun 28, 2022

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
Copy link
Sponsor Member

adriangb commented Jun 28, 2022

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
Copy link
Sponsor Member Author

Kludex commented Jun 28, 2022

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
Copy link
Member

tomchristie commented Jun 28, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants