Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework the version catalog update task #710

Merged
merged 1 commit into from
Jul 17, 2024
Merged

Conversation

melix
Copy link
Contributor

@melix melix commented Jul 16, 2024

This commit completely reworks the version catalog update task. The previous implementation had issues because there was no shared state between passes, so it was impossible to make smarter decisions based on something seen previously.

It also appears that Gradle may, or may not, send all candidates, and the reasons are unclear. This commit changes the algorithm to be stateful instead. It also makes the resolution of metadata parallel, so that the builds are faster.

The algorithm makes sure that candidate versions are passed in order, from the latest release to the oldest one. Subclasses may decide to reject a candidate, in which case the next one will be tested, or they may accept it as a fallback, in which case all versions can potentially be tested. If a version is accepted, then the loop is interrupted and no other candidate is tested.

@melix melix added the enhancement New feature or request label Jul 16, 2024
@melix melix added this to the 7.2.0 milestone Jul 16, 2024
@melix melix requested a review from alvarosanchez July 16, 2024 16:43
This commit completely reworks the version catalog update task.
The previous implementation had issues because there was no shared
state between passes, so it was impossible to make smarter decisions
based on something seen previously.

It also appears that Gradle may, or may not, send all candidates,
and the reasons are unclear. This commit changes the algorithm
to be stateful instead. It also makes the resolution of metadata
parallel, so that the builds are faster.

The algorithm makes sure that candidate versions are passed
in order, from the latest release to the oldest one. Subclasses
may decide to reject a candidate, in which case the next one
will be tested, or they may accept it as a fallback, in which
case all versions can potentially be tested. If a version is
accepted, then the loop is interrupted and no other candidate
is tested.
@melix melix merged commit 789b8a1 into master Jul 17, 2024
3 checks passed
@melix melix deleted the cc/allow-minor-updates branch July 17, 2024 08:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants