Skip to content

fix: use caret constraint for ensemble_test_runner's ensemble dependency - #2345

Open
TheNoumanDev wants to merge 1 commit into
mainfrom
fix/ensemble-test-runner-hosted-constraint
Open

fix: use caret constraint for ensemble_test_runner's ensemble dependency#2345
TheNoumanDev wants to merge 1 commit into
mainfrom
fix/ensemble-test-runner-hosted-constraint

Conversation

@TheNoumanDev

Copy link
Copy Markdown
Member

Summary

melos version breaks when bumping ensemble to a beta version, because it only regex-replaces the leading token of a hosted dependency's version constraint. The compound ">=1.2.50 <2.0.0" form in ensemble_test_runner left the rewrite malformed: ^1.2.50-beta.13 <2.0.0, which dart pub get then rejects. This broke the beta release pipeline (ensemble-v1.2.50-beta.13).

  • tools/ensemble_test_runner/pubspec.yaml: ensemble: ">=1.2.50 <2.0.0""^1.2.50"
  • tools/ensemble_test_runner/example/pubspec.yaml: version: ">=1.2.50 <2.0.0""^1.2.50"

^1.2.50 is semver-equivalent to >=1.2.50 <2.0.0, so this is a no-op for dependency resolution and survives melos's version rewrite intact.

Test plan

  • dart pub get --dry-run resolves cleanly on both files, no dependency changes
  • Reproduced melos version ensemble 1.2.50-beta.13 --yes against this branch in an isolated clone — completes without error, produces ensemble: ^1.2.50-beta.13
  • dart pub get --dry-run on the resulting bumped pubspec resolves successfully

melos version bumps hosted dependency constraints by regex-replacing
only the leading token of the existing constraint string. That breaks
on the compound ">=X <2.0.0" form written here, leaving a mangled,
unparseable constraint (e.g. "^1.2.50-beta.13 <2.0.0") whenever a beta
release runs. "^1.2.50" is semver-equivalent to ">=1.2.50 <2.0.0" and
survives the rewrite intact.

dependencies:
ensemble: ">=1.2.50 <2.0.0"
ensemble: "^1.2.50"

@sharjeelyunus sharjeelyunus Aug 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not right, we don't wanna leave the ensemble versions open ended, this can cause issues

see, how we are handling the real issue in release-melos-version.yml

we are using --scope and --manual-version from melos here

I think the better way would be to have a an input `Beta: true/false" in release-melos-version.yml instead of managing 2 different pipelines

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants