Closed luhn closed 2 years ago
I'm not sure I agree with bumping versions on release. Bumping versions might cause any number of source changes, I don't think we should be messing with the codebase immediately prior to releasing.
Yeah, I'm not sure how we can set a reminder to check whether to check to do a version bump of tools. Usually that happens only when builds fail, but if we pin these tools, then the builds will not fail due to changes in these tools. How and when should we remember to check for the latest versions?
I made the version constraints as loose as possible, so to a limited degree updates will be automatic.
I also think it's okay if we're a bit out of date. It doesn't matter too much if we're using the latest and greatest formatting tools, as long as everybody is on the same version and getting the same results.
If you do really think we need a policy for updating, maybe we update the version for alpha and beta builds only?
Otherwise we'd probably just updated when motivated by support for new language features or Python version/platform/etc compatibility.
I don't think we need a policy on this. It's just formatting/linting and can be run whenever. This LGTM.
Black is now stable! Updated PR accordingly.
I just merged a different PR that changes the versions we support, but also fixes the pypy issue, if you could merge master or rebase on top of master, so CI can run that would be great!
Alright, rebased.
Thank you!
3689 got me thinking that formatting/linting should be stable, PRs shouldn't be required to reformat the entire project to get the tests to pass. This PR adds version constraints to the black, flake8, and isort to produce stable results, according their release policies: