Requiring version number to match upstream Rust version is unnecessary #6683
Comments
|
Could we just disable the test when running clippy tests from the rustc repo? |
… inside the rustc repo. Do not check if clippy version matches rustc version when runnning tests inside the rustc repo. This makes sure that upstream rustc maintainers do not have to deal with our test failing/mismatching versions when the rustc version bump is happening. cc rust-lang#6683
|
Yeah I think @matthiaskrgr's proposed plan is good here. |
|
That seems fine to me, anything that means we don't need to worry about it upstream basically solves my concerns. That said I'm not convinced you want this - but I'm not going to argue that, you know constraints better than I. |
…=flip1995 tests: ignore check_that_clippy_has_the_same_major_version_as_rustc()inside the rustc repo Do not check if clippy version matches rustc version when runnning tests inside the rustc repo. This makes sure that upstream rustc maintainers do not have to deal with our test failing/mismatching versions when the rustc version bump is happening. cc #6683 We already do the "don't run inside the rustc-repo" workaround for the dogfood test: https://github.com/rust-lang/rust-clippy/blob/a507c27660d05f37307369d30bee9e82ce3a11e1/tests/dogfood.rs#L16 changelog: None
camsteffen
added
the
A-infra
|
Yeah I don't think we really need this, but it's easy and convenient to have the version number somewhere in tree. Clippy reports the rustc version on the CLI, and it would be kinda weird if that weren't somewhere in tree as well. |
|
Hm. I guess I don't see that as at all odd. But up to y'all. |
|
Is this fixed by #6684? |
#6499 proposed locking the version number of clippy-the-cargo project to the version number of Rust. In practice, this causes some work for the release team during release week, and I'm not sure why it matters - to my knowledge, clippy isn't depended on by any projects outside the monorepo at rust-lang/rust and this repository, so the version number shouldn't meaningfully affect anyone. Can we remove the tests, at least? Cargo for example does not bump the version number in lockstep with the monorepo, for example, so it doesn't seem like this is all that necessary.
If there's some purpose to the version number then we can work on documenting the process to update in https://forge.rust-lang.org/release/process.html#bump-the-stable-version-number-t-6-days-friday-the-week-before, but it would be great to avoid that - we're hoping to eventually automate the release process pretty much start to finish, and the fewer files need to be edited (particularly relatively complex ones like Cargo.toml) the easier that will be.
The text was updated successfully, but these errors were encountered: