refactor(clippy): enable breaking lint checks #988
Conversation
EdJoPaTo
requested review from
orhun,
mindoodoo,
sayanarijit,
joshka,
kdheepak and
Valentin271
as code owners
There was a problem hiding this comment.
For the to => into change, can you split this off to another PR with a changelog friendly message (i.e. note to_xxx is deprecated use into_xxx instead and the rationale for why). See the changelog for examples of this (these come through verbatim from the PR text unless we specifically write something).
\The breaking change for that is the removal of the to_methods at some point in the future, so no need to note it in the breaking changes doc (unless we want to create a future breaking changes section?).
EdJoPaTo
force-pushed
the
clippy-breaking
branch
from
08a2e34
to
41a31d4
Compare
We need to make sure to not change existing methods without a notice. But at the same time this also finds new methods with mistakes which is what I would like to have.
|
Include this into the next bugfix version or wait for a breaking change release? |
To the best of my understanding, this doesn't break anything, so merging it now. |
We need to make sure to not change existing methods without a notice. But at the same time this also finds public additions with mistakes before they are even released which is what I would like to have. This renames a method and deprecated the old name hinting to a new name. Should this be mentioned somewhere, so it's added to the release notes? It's not breaking because the old method is still there.
We need to make sure to not change existing methods without a notice. But at the same time this also finds public additions with mistakes before they are even released which is what I would like to have.
This renames a method and deprecated the old name hinting to a new name. Should this be mentioned somewhere, so it's added to the release notes? It's not breaking because the old method is still there.