-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let pixi add
pin major versions instead of minor versions
#1562
Comments
Although I agree with you in theory, in practice breaking changes still occur quite frequently for minor bumps, especially in the python world. Thats why we initially settled on pinning the minor version instead of the major. That being said, I would not be opposed to this change. 👍 |
Isn't this a duplicate of #639? |
as stated in #639 (comment), i would prefer semver over major versions |
As mentioned in the issue description, that is only guaranteed to work (to my knowledge) with Rust and Julia. |
The only thing we can do is to always pin zero-leading versions, but I don't think that anyone will be happy with that. |
oh i didn't read this 😅 i'm wondering how many people actually follow this 🤔 |
We could do the same behavior as cargo right? Pin the first (left most) non-zero? So for 3.12.4 it would be <4, but for 0.1.1 it would be <0.2? |
Yes, I think that's also the behavior @pavelzw would like. Thinking about it a bit more, I am not opposed to that anymore. I am just pointing out that semantic versioning works a bit different for Cargo than it does for "vanilla" SemVer. Not only 0.1.0 -> 0.2.0 is allowed to break, but also 0.1.0 -> 0.1.1 |
i would prefer that and call it something like |
(I don't really know if the Cargo people were the first ones actually writing it down) |
The npm caret operator (^) also does this I think: https://docs.npmjs.com/cli/v6/using-npm/semver#caret-ranges-123-025-004 |
I would prefer if the default is no upper bound, as discussed here: https://iscinumpy.dev/post/bound-version-constraints/ Pinning dependencies is more useful for applications than libraries, and for that we would have |
#1516 lets you configure the default. But if no configuration is specified I think we should default to "semver" as proposed in this issue (and implemented in the mentioned PR). |
Problem description
Running
pixi add python
on an empty pixi project currently gives this:I am arguing the expected version range should be this:
This is also the behavior
cargo add
has.For major version zero, the situation is a bit more complicated. According to SemVer there are no stability guarantees at all:
Rust and Julia define that different, but to my knowledge, most ecosystems don't overrule that specification.
For major zero, I think people will have to choose the pinning strategy themselves.
Pinning the major versions instead of the minor versions still makes sense in my opinion.
The text was updated successfully, but these errors were encountered: