Closed thewh1teagle closed 1 month ago
I don't think Cargo allows upgrade pre-release versions at this moment. You may need to specify each crate separately with the --precise
flag. See the relevant doc.
That said, maybe at this moment before figuring out the correct SemVer for pre-releases, --breaking
should not touch nor upgrade any of them.
cc @torhovland
Yes, it looks like we should not try to upgrade (or downgrade) dependencies that are currently on a pre-release. Except maybe if there is a proper release that is higher than the current pre?
@epage Thoughts?
I will be away for a few weeks now, so if anybody wants to tackle this, feel free.
Nice to see that we are faster than cargo-edit
🎉
Yes,
--breaking
Also, being faster is easy; cargo-edit does not use the sparse registry.
If no one on this, I will take a look
I don't know if this issue was properly addressed here — the currently nightly means that something like derive-more, on version 1.0.0-beta.7
, isn't currently being upgraded to 1.0.0
!
I personally pretty strongly feel that this upgrade should be done automatically with the breaking flag?
I think that's was @torhovland was getting at with:
Except maybe if there is a proper release that is higher than the current pre?
Also, in an ideal world, I do feel like it should bump pre-releases if there are several of them — what was the issue with upgrading automatically from 1.0.0-beta.6
to 1.0.0-beta.7
? Obviously we shouldn't go from a stable release to a pre-release automatically, but if we're already on a pre-release, I do think we should track it and then automatically upgrade to stable when that's published.
What do others think about that approach?
@TheLostLambda Much appreciate your options.
I don't know if this issue was properly addressed here
My PR just prevents pre-release
won't downgrade.
What do others think about that approach?
If version is currently stable / non-pre-release, then ignore pre-releases
If version is currently a pre-release, upgrade it as normal — including upgrading to the stable version!
I saw @torhovland had submitted serval PR maybe relevent to your suggestions. If not, I am very pleasure to submit anthor PR to solve this issues.
Thanks for the swift response!
My PR just prevents
pre-release
won't downgrade.
That's good to know, that's what it looked like to me too!
I saw @torhovland had submitted serval PR maybe relevent to your suggestions.
And good to know — I'll take a look!
Perhaps we should re-open this issue if it was only partially addressed by your PR?
I don't know if this issue was properly addressed here — the currently nightly means that something like derive-more, on version
1.0.0-beta.7
, isn't currently being upgraded to1.0.0
!I personally pretty strongly feel that this upgrade should be done automatically with the breaking flag?
I think that's was @torhovland was getting at with:
Except maybe if there is a proper release that is higher than the current pre?
Also, in an ideal world, I do feel like it should bump pre-releases if there are several of them — what was the issue with upgrading automatically from
1.0.0-beta.6
to1.0.0-beta.7
? Obviously we shouldn't go from a stable release to a pre-release automatically, but if we're already on a pre-release, I do think we should track it and then automatically upgrade to stable when that's published.What do others think about that approach?
- If version is currently stable / non-pre-release, then ignore pre-releases
- If version is currently a pre-release, upgrade it as normal — including upgrading to the stable version!
Isn't this what was pointed out in https://github.com/rust-lang/cargo/pull/14250#discussion_r1686796460 and is listed in the last checkbox in https://github.com/rust-lang/cargo/issues/12425#issuecomment-2186198258
@Skgland That's a good eye! Sorry for missing those!
The first one, https://github.com/rust-lang/cargo/pull/14250#discussion_r1686796460, seems to correctly point out that the first two of those tests are "unsolved" things that we'd like to support, and I agree we should support them!
The second link, the last checkbox in https://github.com/rust-lang/cargo/issues/12425#issuecomment-2186198258 I think matches my suggestion! These both I think are good ideas:
- 2.0.0-beta.1 to 2.0.0-beta.2
- 2.0.0-beta.1 to 2.0.0
Though I, like the author, am less sold on:
- I am not sure about if 2.0.0-beta.1 to 3.0.0-beta.1 should works
Perhaps that's better as 2.0.0-beta.1
to 3.0.0
? That way you have to opt into each pre-release series, but you never "skip over" a chance to return to stable!
EDIT: Either way, I think this issue should be reopened? Or some new issue made to track that last checkbox! EDIT2: I'm bad at reading! I misinterpreted the first link you sent! That's my bad!
@TheLostLambda for the problem that was reported in this Issue, it has been resolved (just because it has prerelease in the title does not mean ti covers every prerelease case). This should not be re-opened. If there is another problem with the behavior, open an issue for it.
Problem
Hello! I use
cargo update
fromnightly
release to upgrade dependencies However looks likecargo
doesn't respect beta semver:Notice the line
Steps
Then compare with https://crates.io/crates/tauri/versions
Possible Solution(s)
Respect beta versions
Notes
Also, I wanted to say that I'm really looking forward to seeing this feature, as I'm using cargo upgrade from
cargo-edit
, which takes tremendous time to upgrade dependencies, while cargo update from nightly does the same job much quicker.Version