Modernize crate #132
Modernize crate #132
Conversation
| .version(env!("CARGO_PKG_VERSION")) | ||
| .settings(&[ | ||
| AppSettings::UnifiedHelpMessage, | ||
| AppSettings::DeriveDisplayOrder, | ||
| AppSettings::DontCollapseArgsInUsage, | ||
| ]) | ||
| // as this is used as a Cargo subcommand the first argument will be the name of the binary |
There was a problem hiding this comment.
These are all default now
| #![deny(warnings)] | ||
|
|
| .multiple(true) | ||
| .number_of_values(1) | ||
| .takes_value(true) | ||
| .short('F') |
There was a problem hiding this comment.
a little bonus, -F was added in 1.62.0
|
Can we get some more eyes on this, don't want to accidentally break anything I've tried to find usecases which don't work anymore but can't find any. |
|
ping @rust-embedded/tools |
|
I'm confused, is actions/checkout@v4 now merging ::edit:: apparently it's been this way for atleast 4 years now, I had no clue :) |
Emilgardis
force-pushed
the
modernize
branch
2 times, most recently
from
59eb3d5 to
50bf217
Compare
also adds `-F` shorthand
Emilgardis
force-pushed
the
modernize
branch
from
50bf217 to
f16328a
Compare
|
What's the reason for moving the MSRV to 1.72.1? Debian is shipping 1.70. |
|
The reason is because we can, and we dont have a policy except that we may bump the msrv whenever according to https://github.com/rust-embedded/wg/blob/master/rfcs/0523-msrv-2020.md That is to say, no particular reason to choose 1.70 or 1.72, i just picked the latest |
|
What is the lowest Rust version that actually work for this crate? i.e. what actually is our minimum supported Rust Version at this time? |
|
clap is the limiter pretty sure, so 1.70 |
|
I think we shouldn't be too agressive with moving the MSRV. It's certainly worthwile to be a bit conservative here. Also if we already know that the bump of Unfortunately I've made the experience that between clap 2 and clap 3 there had been a ton of oh so subtle changes which broke some uses of my tools and took quite some time to discover and fix since the authors decided that it was undocumented behaviour and thus fair to silently change -- I'm a bit worried that we might run into similar issues. At the very least we would have a big fat warning in a few places to alert people to the possibility of unintended CLI breakage due to the |
|
we could also recommend installation with |
|
bors r+ |
|
need to migrate on |
No description provided.