pixi upgrade incorrectly overwrites specific Python version constraints across different features

[ZerounNet]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

Commands I ran and their output:

# Initial state: python version constraints are specific to each feature (e.g., 3.11, 3.12, etc.)
pixi upgrade

pixi.toml/pyproject.toml file that reproduces my issue:

[workspace]
channels = ["conda-forge"]
name = "bug_report"
platforms = ["linux-64", "win-64"]
version = "0.1.0"

[dependencies]
ruff = ">=0.15.9,<0.16"
ty = ">=0.0.29,<0.0.30"
uv = ">=0.11.5,<0.12"
numba = ">=0.65.0,<0.66"

[environments]
default = { features = ["py314"] }
py311 = { features = ["py311"] }
py312 = { features = ["py312"] }
py313 = { features = ["py313"] }
py314 = { features = ["py314"] }

[feature.py311.dependencies]
python = ">=3.11,<3.12"

[feature.py312.dependencies]
python = ">=3.12,<3.13"

[feature.py313.dependencies]
python = ">=3.13,<3.14"

[feature.py314.dependencies]
python = ">=3.14,<3.15"

Issue description

When a project has multiple features defined with different Python version ranges, running pixi upgrade incorrectly updates all features to the highest version range found in the file, ignoring the original constraints.

Expected behavior

pixi upgrade should respect the existing version ranges. For example, feature.py311 should only update the patch version of Python 3.11 (if any) and remain within the ">=3.11,<3.12" constraint.

Actual behavior:
pixi upgrade seems to identify the highest version requirement across the entire file and applies it to all features, effectively breaking the multi-version environment setup:

[feature.py311.dependencies]
python = ">=3.14.4,<3.15"  # This was originally ">=3.11,<3.12"

[feature.py312.dependencies]
python = ">=3.14.4,<3.15"  # This was originally ">=3.12,<3.13"
# ... and so on

[baszalmstra]

I think you are looking for pixi update instead of upgrade.

[ZerounNet]

I think you are looking for pixi update instead of upgrade.

I am definitely looking for upgrade, not update.

I use a standardized routine to keep all my project manifests up-to-date:

pixi upgrade && cargo upgrade && bunx npm-check-updates -u

All these tools are designed to modify the manifest files (pixi.toml, Cargo.toml, package.json) to the latest possible versions.

[ruben-arts]

We don't have the concept of a "pinned" dependency yet. cargo does this with =1.2.3 IIUC. This would first need to be implemented in some way. I would be interested in discussing options to define that as I've ran in to this issue myself some times.