Make DEFAULT_INTERDEPENDENCY_RANGE "workspace:~"

[CraigMacomber]

Description

flub bump has two use cases:

1. Setting the dependency versions during release via tools/pipelines/templates/include-set-package-version.yml which uses update-package-version.sh. This case sets --interdependencyRange unconditionally and should not be impacted by the default.
2. running flub bump to update the version for releases (usually via flub release). This wants to leave the dependencies unchanged.

Since dependencies in main use "workspace:~", this second case has been making unwanted modifications when trying to just bump the version.

Future changes should separate these two use cases into a tool that bumps versions and a tool which sets the inter dependency ranges.

While evaluating use of DEFAULT_INTERDEPENDENCY_RANGE, bumpReleaseGroup which uses it was found, but is dead code and was deleted.

DEFAULT_INTERDEPENDENCY_RANGE was then moved next to its only remaining use getDefaultInterdependencyRange.

Breaking Changes

Anything that relies on the current getDefaultInterdependencyRange will be impacted.

Since that is a InterdependencyRange meaning it only applies to "dependencies between packages within the same release group." this change seems like it's an improvement.

The only other user of getDefaultInterdependencyRange is doReleaseGroupBump, which seems like it should fix previously unknown issue where it has the same issue, so this is likely fine.

Reviewer Guidance

The review process is outlined on this wiki page.

[tylerbutler]

Since dependencies in main use "workspace:~", this second case has been making unwanted modifications when trying to just bump the version.

I'm confused about the failing case. I tried to repro using flub bump client -t patch -x (-x to skip install, commit, etc). and only the versions were bumped. The default interdependency range for each release group is configured in the fluidBuild config, so it's not clear to me how a different value is getting picked up. Does it only repro when doing a bump as part of flub release?

[tylerbutler]

I'm confused about the failing case. I tried to repro using flub bump client -t patch -x (-x to skip install, commit, etc). and only the versions were bumped. The default interdependency range for each release group is configured in the fluidBuild config, so it's not clear to me how a different value is getting picked up. Does it only repro when doing a bump as part of flub release?

I figured this out. I thought I was running the latest version of flub, but in fact I was using a very old version, 0.41. Once I used the latest version I reproed the failure easily.

I'm not opposed to some of the changes here, especially the dead code cleanup, but I think a better change to address the bug is to add back-compat support so that the existing settings n the fluid-build config are loaded correctly. I opened #22628 with that change.

[microsoft-github-policy-service[bot]]

This PR has been automatically marked as stale because it has had no activity for 60 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!