v3 release

[mjs]

I'm thinking that we can cut a v3.0.0 release soon.

@JohnVillalovos are you planning to do any more type hints as I'm happy to wait for those to be more complete?

If I can find some time I'd like to try simplifying idle_check() for the release but I also don't want to hold it up for that.

@NicolasLM @axoroll7 thoughts?

[NicolasLM]

It seems like a good time for a release, besides the idle thing it seems that no one is planning breaking changes.

[JohnVillalovos]

@mjs I would say go ahead and do a release as the type-hints are going to take some time.

[axoroll7]

Thank you for asking for my thoughts. I have nothing to add.

[JohnVillalovos]

@mjs I vote for a release sooner rather than later. Can always do another release after that.

Also not sure if there would be any interest in using something like https://github.com/commitizen-tools/commitizen in the future. With that and Python Semantic Release (https://github.com/python-semantic-release/python-semantic-release) it can make it easier to automate releases.

Basically with comittizen just add a keyword on the Git subject line. Usually one of: build ci chore docs feat fix perf refactor revert style test

Over in python-gitlab we have it setup: https://github.com/python-gitlab/python-gitlab/blob/main/.github/workflows/release.yml

Example of automated releases: https://github.com/python-gitlab/python-gitlab/releases

[mjs]

Thanks for the tips for automating releases. I've been wondering about reducing friction around doing IMAPClient releases so this is great timing. Right now I have a long checklist and writing up the release notes is a drag.

[mjs]

My concern with something like comittizen is that it'll be difficult to get everyone who contributes to follow the approach. We get plenty of one-off contributions and it's perhaps unreasonable to expect everyone to get familiar with commitzen.

I've just noticed that Github has built-in release notes generation which is driven by pull request labels. That seems a little more lightweight.

https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes

[JohnVillalovos]

My concern with something like comittizen is that it'll be difficult to get everyone who contributes to follow the approach. We get plenty of one-off contributions and it's perhaps unreasonable to expect everyone to get familiar with commitzen.

You wouldn't have to use or enforce comittizen. As long as you and other people followed the convention on the commit subject line, but it would be optional. Then could use Python Semantic Release.

I don't have any experience with the GitHub release notes generation. But if it works, sounds good to me.

[mjs]

Here's the setup for GitHub generated release notes: #547

The approach is quite straightforward and just relies on labels being added to PRs which is something that anyone can do, even after the PR has merged. It doesn't rely on any given PR author having to learn the process or install an additional tool.

[mjs]

Automated release notes are configured and I've labelled all recent PRs with the breaking and enhancement tags as appropriate so that release notes will get created.

This is the final v3 changes: #553

[mjs]

Release done!

https://pypi.org/project/IMAPClient/3.0.0/
https://github.com/mjs/imapclient/releases/tag/3.0.0