Skip to content

Conversation

@ddabble
Copy link
Member

@ddabble ddabble commented Dec 9, 2025

Description

Probably time for a release :)

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have run the pre-commit run command to format and lint.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • I have added my name and/or github handle to AUTHORS.rst
  • I have added my change to CHANGES.rst
  • All new and existing tests passed.

Also added EOL date to the changelog entry for dropping Python 3.9.
@ddabble ddabble requested a review from tim-schilling December 9, 2025 17:53
@ddabble ddabble added the release Pull requests that prepare for a new release label Dec 9, 2025
@codecov
Copy link

codecov bot commented Dec 9, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Member

@tim-schilling tim-schilling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@ddabble ddabble merged commit 6afee6d into master Dec 11, 2025
55 checks passed
@ddabble ddabble deleted the prepare-release-3.11.0 branch December 11, 2025 13:41
@tim-schilling
Copy link
Member

@ddabble that release process failure was due to creating the github release manually. I think it can be ignored since everything has been uploaded properly (except the signed artifacts to the GH release, but that matches prior releases).

@ddabble
Copy link
Member Author

ddabble commented Dec 11, 2025

@tim-schilling Ah right, I agree that we can probably ignore it, since the workflow logs say that Release.tag_name already exists 👍

Btw, seems like I've missed some pieces of information about this process; since you're mentioning creating GitHub releases manually, is there a way to create them automatically? 🤔 As far as I had understood, the process to create a new release is:

  1. Draft a new release
  2. Approve the automated deployment

@tim-schilling
Copy link
Member

The release process should be:

  1. Prepare version update PR
  2. Merge version update
  3. Create tag locally
  4. Push tag
  5. Approve deployment
  6. [Automated] System will create the GitHub release for the new tag
  7. [Optional] Edit release notes (I like to remove the pre-commit mentions personally)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release Pull requests that prepare for a new release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants