Prepare for release 3.11.0

[ddabble]

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.

[codecov]

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.

[tim-schilling]

🚀

[tim-schilling]

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

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

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)

[ddabble]

@tim-schilling Ah I see, thanks! 😊 Is that process documented anywhere among Django Commons' repos? I guess parts of it can kind of be inferred from releases.md in the best-practices repo, but I think it could be useful to have written down explicitly and unambiguously 🙂

Also, could it be an idea to allow manually creating GitHub releases? Or is there some technical or security-related reason for preferring automatically creating them after a tag has been pushed?

[tim-schilling]

I think you're paying the price of me transferring it and skipping the step of doing a walk-through of a release with you. I'm sorry about that.

Agreed that clearer docs is a great idea. We'd also want the repositories to maintain their own deployment documentation. The release github action can be tweaked to the maintainers' preferences.

[tim-schilling]

I did the latter half here: #1573