isort needs a more stable minor and patch release cadence.
Now that issues are able to be resolved quickly, it is tempting to push out fixes and new features as they happen.
However, a fully rolling release approach is not the best fit for a linter / formatter. Even with good test coverage and best intentions - mistakes do still happen.

See:

• CI: pin isort < 5.4.0 pandas-dev/pandas#35705
• CI / Checks (pull_request) on Github Actions failing with isort 5.3.2 -> 5.4.0 pandas-dev/pandas#35703

And the root cause of both:

• Isort 5.4.0 with combine-as drops comments on some imports #1381

isort 5 has already adopted a more mature release policy and included formatting target guarantees: https://timothycrosley.github.io/isort/docs/major_releases/release_policy/. I think it is time for the project to move in the same direction for minor and patch releases.

As a start, I'm proposing:

• Minor releases (releases that can include new features) no more than once a month.
• Patch releases aim for no more than twice a month. Though significant errors should always be fixed as quickly as they are discovered.

Community feedback on what cadence would make the most sense would be greatly appreciated!

~Timothy