Isort: Release advice

[omry]

This is an advice, not an issue:

First of all, congrats of 5.0, looks like a great release based on the release notes (did not yet had the chance try it out yet).
I noticed that you had two patch releases in two hours after 5.0.

My advice is to use a release candidate next time.
5.0.0rc1 would not get installed automatically by users, but people can install it with a specific version of by using --pre in the pip command (pip install --upgrade --pre isort).
Making it a release candidate would set expectations and you would not be under pressure to fix any new issues because the world is on fire.
people opting to use the rc would still be able to provide feedback, and once you have confidence that there are no much little issues you can finally flip the switch and make it a proper release.

I have been doing it with my projects and it strikes a good balance between managing pressure, allowing users to use cutting edge versions that are not from master and getting feedback for them.

That's it, feel free to close :)

[jedie]

And it would be good if changes to the CLI would initially only give warnings...

So my CI pipeline breaks e.g.: https://github.com/jedie/django-user-secrets/runs/837122007?check_suite_focus=true and changes needed to fix this: https://github.com/jedie/django-user-secrets/commit/84cd1cae003fc934d3de0a5848af6a56e1473c07

[timothycrosley]

Thanks to both of you! I couldn't agree more on both fronts, and will keep this as an open tasks to collect additional release process feedback and make sure to incorporate them in the future into the isort project. While, I was aware of both of these options, the release date slipped for isort after already being delayed for months - so I jumped the gun. However, having all these collected and than codified into isorts process will ensure that this doesn't become a pattern for the project.

[omry]

A release candidate would allow you to start collecting feedback before the official release date, from users that are expecting some instability.
I find this invaluable for my own projects (Hydra, OmagaConf).

I personally believe that high quality software and strict project deadlines are not a good mix, but that's just me preference.
The benefit of a release is that you start collecting feedback. for a project like yours, which so many dependent projects - this might be more akin from drinking from a fire-hose if you do not start collecting feedback from a small but cooperative bunch of people.

[timothycrosley]

Closing this now, as I believe sufficient time has been given to collect feedback from more users.

The takeaway from this has been distilled into an official release policy for the isort project, additional feedback can take the form as a pull request against this policy:

https://timothycrosley.github.io/isort/docs/major_releases/release_policy/

Thanks everyone!

~Timothy

[omry]

The release policy makes a lot of sense.