Skip to content

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Feb 6, 2025

This pull request changes the compat entry for the ReactantCore package from 0.1.5 to 0.1.5, 0.1 for package ..
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

@@ -74,7 +74,7 @@ Preferences = "1.4"
PythonCall = "0.9"
Random = "1.10"
Random123 = "1.7"
ReactantCore = "0.1.5"
ReactantCore = "0.1.5, 0.1"
Copy link
Member

Choose a reason for hiding this comment

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

Wut

Copy link
Member

Choose a reason for hiding this comment

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

@DilumAluthge
Copy link

For my reference, this looks like the linked CompatHelper run: https://github.com/EnzymeAD/Reactant.jl/actions/runs/13169135948

@DilumAluthge
Copy link

@giordano Could you temporarily modify the CompatHelper config in this repo to point to my debugging branch (JuliaRegistries/CompatHelper.jl#520)?

That will let us do debugging in a quicker cycle, without needing to wait for a CompatHelper release every time.

@giordano giordano deleted the compathelper/new_version/2025-02-06-00-25-45-134-02756644040 branch February 7, 2025 00:28
@giordano
Copy link
Member

giordano commented Feb 7, 2025

https://github.com/EnzymeAD/Reactant.jl/actions/runs/13190625523/job/36822782289#step:7:204

 Info: continue_with_pr = true
│   dep.latest_version = v"0.1.4"
│   dep.version_spec = VersionSpec("0.1.5 - 0.1")
│   dep.package.name = "ReactantCore"
│   dep = CompatHelper.DepInfo(CompatHelper.Package("ReactantCore", Base.UUID("a3311ec8-5e00-46d5-b541-4f83e724a433")), v"0.1.4", VersionSpec("0.1.5 - 0.1"), "0.1.5")
└   dep.version_verbatim = "0.1.5"
Already on 'main'
Your branch is up to date with 'origin/main'.
Switched to branch 'compathelper/new_version/2025-02-07-00-35-42-605-02316059808'
[ Info: Attempting to commit...
[compathelper/new_version/2025-02-07-00-35-42-605-02316059808 47fa9da] CompatHelper: bump compat for ReactantCore to 0.1 for package ., (keep existing compat)
 1 file changed, 3 insertions(+), 3 deletions(-)

Side note, you should be able to work in a fork of this repo without waiting for others to do this, no?

@giordano
Copy link
Member

giordano commented Feb 7, 2025

Is this because ReactantCore 0.1.5 hasn't been registered yet? The suggested change is still silly though.

@DilumAluthge
Copy link

Is this because ReactantCore 0.1.5 hasn't been registered yet? The suggested change is still silly though.

Ah, I didn't realize ReactantCore 0.1.5 wasn't registered.

Yeah, that's likely the problem.

CompatHelper is quite naive, and basically works like this:

  1. Get the list of all registered versions of dep. In this example, the list is [v0.1.0, v0.1.1, v0.1.2, v0.1.3, v0.1.4].
  2. Take the maximum of the list from step 1. In this example, the maximum is v0.1.4.
  3. Test if value_from_step3 in Pkg.Versions.semver_spec(current_compat_entry). So in this case, it tests if v0.1.4 is "in" the compat entry ^0.1.5. The answer in this example is false.
  4. If the answer from step 4 is false, open a PR.

CompatHelper was originally designed as a companion to the new AutoMerge rules in the General registry, which is uses the registry as the source of truth for package versions.

For this use case (version not registered yet), we'll have to figure out a way to detect this situation.

@DilumAluthge
Copy link

DilumAluthge commented Feb 7, 2025

The way the PR is generated is also quite naive.

First, take the result of step 2, which in this case is v0.1.4.

Next, if that version number is >= 1.0.0, drop the minor and patch. Otherwise, drop the patch. So in this example, we convert v0.1.4 to "^0.1" (just dropping the patch). In contrast, if the result from step 2 had been v77.88.99, then we would have converted v77.88.99 to "^77" (dropping both minor and patch, keeping only major).

So now we have our "new addition", and we basically just do the equivalent of new_compat_entry = old_compat_entry * ", " * our_new_addition. So in our example, we do the equivalent of new_compat_entry = "^0.1.5" * ", " * "^0.1" which equals "^0.1.5, ^0.1". And then we open a PR to change the compat entry to "^0.1.5, ^0.1".

@DilumAluthge
Copy link

This specific situation (where the compat entry is exactly of the form "xx.yy.zz") is probably something we can detect with a regex and special-case. I'll work on a PR.

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.

3 participants