feat(core): range constraints for internal dependencies

[goulvenclech]

Fixes #175 . Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

Note: Constraint validation is currently implemented for Cargo packages only. Other ecosystems will skip validation with an informative message until constraint extraction is implemented for them.

What has changed?

• crates/sampo-core/src/adapters/cargo.rs: Added should_update_dependency_version() helper — pinned versions (bare semver) are updated, range constraints (^, ~, *, etc.) are preserved. Added is_dependency_pinned() and raw_dep_version() helpers. Updated update_standard_dependency_item, update_inline_dependency, and update_table_dependency to use them.
• crates/sampo-core/src/release.rs: validate_dependency_constraints() now uses real constraints from ManifestMetadata::get_dependency_constraint() for Cargo packages instead of hardcoded "*". Removed #[allow(dead_code)].
• crates/sampo-core/src/types.rs: ConstraintCheckResult enum and ConstraintViolation struct.
• crates/sampo-core/src/errors.rs: ConstraintViolation error variant.
• crates/sampo-core/src/adapters.rs: check_dependency_constraint method on PackageAdapter.
• crates/sampo-core/src/adapters/{npm,hex,pypi}.rs: Stubs returning Skipped.
• crates/sampo-core/src/lib.rs: Export new types.

How is it tested?

• crates/sampo-core/src/adapters/cargo/cargo_tests.rs: 10 new tests for range constraint preservation (caret, tilde, wildcard — satisfied & unsatisfied, all dependency formats). Plus the existing 22 constraint-checking tests.
• crates/sampo-core/src/release_tests.rs: 4 new integration tests — range preserved through release, pinned updated through release, constraint violation blocks release in fixed groups, constraint violation warns but succeeds without groups.
• crates/sampo-core/src/types.rs: Unit tests for ConstraintCheckResult methods and Display implementations.

How is it documented?

• crates/sampo/README.md: Added note about range constraint support in internal dependencies.

[sampo-s-bot]

🧭 Changeset detected

Merging this PR will release the following updates:

sampo (Cargo) — minor version bump

Minor changes

• ⚠️ breaking change: Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

Note: Constraint validation is currently implemented for Cargo packages only. Other ecosystems will skip validation with an informative message until constraint extraction is implemented for them.

sampo-core (Cargo) — minor version bump

Minor changes

• ⚠️ breaking change: Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

Note: Constraint validation is currently implemented for Cargo packages only. Other ecosystems will skip validation with an informative message until constraint extraction is implemented for them.

sampo-github-action (Cargo) — minor version bump

Minor changes

• ⚠️ breaking change: Sampo no longer overwrites range constraints for internal dependencies (or skips them silently in some cases). During release planning, if a planned version bump doesn't satisfy a range constraint (e.g. bumping foo to 2.0.0 when another package requires foo = "^1.0"), you'll get either an error (for packages in fixed or linked groups) or a warning, instead of silently skipping. Pinned versions (e.g. foo = "1.2.3") are still bumped automatically.

Note: Constraint validation is currently implemented for Cargo packages only. Other ecosystems will skip validation with an informative message until constraint extraction is implemented for them.

[goulvenclech]

Open questions :

1. Currently, constraint validation only applies to ignored packages (not in release), while ALL packages in the release have their dependency versions overwritten with exact versions (e.g., ^1.0 → 1.3.0). Ranges should be preserved when still satisfied (^1.0 stays ^1.0 for 1.3.0), and only pinned versions should be updated.
2. If constraint validation iterates all members without applying ignore rules, ignored/unpublished packages can emit hard errors (for fixed/linked groups) and block releases. Does this respects should_ignore_package philosophy?
3. With this new feature, planning will always loads Cargo metadata when any Cargo package exists, which requires a working cargo binary even for dry‑run plans... Am I happy with this new requirement?

[rafaeelaudibert]

With this new feature, planning will always loads Cargo metadata when any Cargo package exists, which requires a working cargo binary even for dry‑run plans... Am I happy with this new requirement?

The usual way to install sampo right now is via cargo install, correct? Which implies the existence of cargo in most installations.