Let pixi add pin major versions instead of minor versions

[Hofer-Julian]

Problem description

Running pixi add python on an empty pixi project currently gives this:

[dependencies]
python = ">=3.12.4,<3.13"

I am arguing the expected version range should be this:

[dependencies]
python = ">=3.12.4,<4"

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:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

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.

[baszalmstra]

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. 👍

[pavelzw]

Isn't this a duplicate of #639?

[Hofer-Julian]

Isn't this a duplicate of #639?

I think it's a good idea to link it here. But considering that it started with a completely different proposal (removing upper bounds all together) I would prefer to close #639 and keep this one.

[pavelzw]

as stated in #639 (comment), i would prefer semver over major versions

[Hofer-Julian]

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.
According to SemVer zero leading versions can break anytime, including patch releases.

[Hofer-Julian]

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.

[pavelzw]

oh i didn't read this 😅 i'm wondering how many people actually follow this 🤔
at least i'm always bumping the minor part for breaking changes in pre-v1

[baszalmstra]

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?

[Hofer-Julian]

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

[pavelzw]

i would prefer that and call it something like semver (even though it's not strictly semver). as long as we properly document what it's doing, i think this is okay

[Hofer-Julian]

i would prefer that and call it something like semver (even though it's not strictly semver). as long as we properly document what it's doing, i think this is okay

cargo-semver :P

(I don't really know if the Cargo people were the first ones actually writing it down)

[baszalmstra]

The npm caret operator (^) also does this I think: https://docs.npmjs.com/cli/v6/using-npm/semver#caret-ranges-123-025-004

[maurosilber]

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 pixi.lock, woudn't we?

[baszalmstra]

#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).