Remove need to predict versions in bigger changesets

[Xiphe]

This is a follow-up to #11

Given I have a multi-package project
And a package button at v2.3.4
And a package dialog at v3.4.5 that has a dependency on button
And I am on a feature branch

When I introduce a BREAKING CHANGE on button
Then I expect the button to be released as v3.0.0 one I merge my branch into master

When I adjust the dialog to be compatible to the button changes
Then I need to ensure that the new version of the dialog depends on the button that includes the API change
BUT I don't know (for sure) the version in which my BREAKING CHANGE on button will be releasaed. So I need to predict the future version and may be wrong

---

Proposal:

Adjust the logic described here: #11 (comment) to use a caret range instead of a hyphen-range if both packages, the dependant and the dependency have received direct changes.

[Xiphe]

I'd be interested to see how you implemented this but was not able to find the implementation by a quick look at the changeset of #15. Could point me to the source?

[matthias-reis]

It's not contained. That was a loose reference to this commit, because the actual problem is introduced with this feature. When you deal with fixed dependencies instead of ranges, this problem doesn't exist, because by definition all relations are automatically correct.

Autoprediction seems to have leaks as well, because the change in A could relate to a totally different topic, so the following automatic change of relation B in A would be wrong.

I personally have no idea yet how to implement this, except including a "magic tag as a dependency", that is being replaced by the correct version while running the pre step.

E.g.

{
  "name": "my-dialog",
  "dependencies": {
    "my-button": "rlsr"
  }
}

becomes

{
  "name": "my-dialog",
  "dependencies": {
    "my-button": "^1.2.0"
  }
}

So your solution is automatic (+) but would trigger cascading updates even if it's not necessary, while the other one here needs a conscious manual step.

[Xiphe]

Oh i have not noticed that the issue is still open. My fault sry :)

[Xiphe]

I like the idea with using a rlsr version as a placeholder. I had also thought about a special annotation in the commit message.

fix(my-dialog): ack changes of my-button

rlsr-fix-to-latest:
 - my-button

The reasoning behind my initial idea was based on the assumption that each commit in master will trigger a release (as lone as the pipeline is green). And my experience from working in that state is that all releases are basically self-containing. Only one package receives features and others may implement them. So even the possibility for unnecessarily close ranges in updates is there, I think the problem would not be that great.