Support lenient versions in GCV to enable Jakarta bridge migrations

[mglazer]

Before this PR

We were unable to run subprojects with different versions from the versions.lock

After this PR

==COMMIT_MSG== Support lenient versions in GCV to enable Jakarta bridge migrations

In order to support libraries like tracing-java which need both javax libraries and jakarta libraries, we need to have some way of hosting both in the same repository, but not having GCV force our versions of all subprojects up to that version as well.

This introduces a mode in GCV (which is very much frowned upon anyone using), which instead of forcing strict versions from the versions.lock file, instead makes them prefer, this then lets subprojects force the version to strict, which overrides any past or future version constraints.

I'm not super happy with this solution since it does violate some of the principles of GCV, but the problem we're trying to solve with the Jakarta migration is very much non-compliant. ==COMMIT_MSG==

Possible downsides?

Anyone but a small handful of projects uses this new feature.

[changelog-app[bot]]

Generate changelog in changelog/@unreleased

Type See change types. Select one:

• [ ] Feature
• [x] Improvement
• [ ] Fix
• [ ] Break
• [ ] Deprecation
• [ ] Manual task
• [ ] Migration

Description Support lenient versions in GCV to enable Jakarta bridge migrations

In order to support libraries like tracing-java which need both javax libraries and jakarta libraries, we need to have some way of hosting both in the same repository, but not having GCV force our versions of all subprojects up to that version as well.

This introduces a mode in GCV (which is very much frowned upon anyone using), which instead of forcing strict versions from the versions.lock file, instead makes them prefer, this then lets subprojects force the version to strict, which overrides any past or future version constraints.

I'm not super happy with this solution since it does violate some of the principles of GCV, but the problem we're trying to solve with the Jakarta migration is very much non-compliant.

Check the box to generate changelog(s)

• [x] Generate changelog entry

[mglazer]

Unfortunately testing this out on a real project in integration doesn't work as I'd have hoped, the strict locks from the subprojects prevent the configuration from being resolvable.