First, my other dependencies usually deliver something of value to the customer (and so I deliver my other dependencies to the end-user installation.) Second, when I need to change code to accommodate other dependencies, it is usually limited to a couple of files, sometimes to a couple of modules; this change will touch much, much more than that. Third, my other dependencies at least play nice by implementing semver and bumping a major release on a breaking change.
Nothing of that applies to this change.
> fix issues
Which weren't "issues" at all just this morning.
To your other issues, just do not upgrade. There is no need to upgrade everything a few days after release. I always lock ruff to version I like and upgrade whenever it is convenient.
> upgrade whenever it is convenient
In my codebase, and with my environment, the best answer is never. We'll have to pick a second-best answer though.
That is why gofmt is so great. As the saying goes: gofmt’s style is nobody’s favorite, yet gofmt is everybody’s favorite.
Another option would be to leave both topics alone and go on with our lives, improving the product, fixing bugs, implementing new features, and generally giving customers a better product and shareholders more value, while respectfully agreeing to disagree on the issues of style.