[maratc]

I find it hard to look at ruff as at "other dependencies."

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.

[jbvlkt]

I also do not like if project stays on 0 version to break compatibility with every minor version. This is the problem with many rust tools and libraries. I think it is unfair to do that years after first release and with healthy community. But it is a tradeoff and not using ruff is in my opinion worse.

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.

[maratc]

I find it kinda amusing that we seem to have an endless and useless discussion on "what version of ruff to use" now when you kinda implied that you have some sort of a solution to these endless, useless discussions -- in a form of "just use ruff."

> 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.

[jbvlkt]

Look at ruff blog, they provide config which disables newly added rules. So you can use that and everything will be the same. I have tried ruff today on multiple projects at work and nothing changed because we already use more rules than default. There was zero discussion about that everyone is ok with using linters, formatters and similar tools like deptry or uv-sort.

[maratc]

I've tried that and I've got only 2900 errors -- which weren't errors at all just yesterday.