CompatHelper: bump compat for "ImageCore" to "0.9"

[github-actions]

This pull request changes the compat entry for the ImageCore package from 0.8.3 to 0.8.3, 0.9.

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.

[kimikage]

Reminder: #879 (comment)

[codecov]

Codecov Report

Merging #954 (cecc793) into master (77b3180) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #954   +/-   ##
=======================================
  Coverage   85.96%   85.96%           
=======================================
  Files           9        9           
  Lines        1026     1026           
=======================================
  Hits          882      882           
  Misses        144      144           

Impacted Files	Coverage Δ
src/Images.jl	14.28% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 77b3180...cecc793. Read the comment docs.

[kimikage]

@johnnychen94, I had missed the fact that Images v0.24.0 had been released (registered). Strictly speaking, wouldn't it be better to fix the compatibility with ColorVectorSpace v0.9 first and release Images v0.24.1?

Formally, there can be cases that are incompatible with ImageCore v0.9, but are supposed to be compatible with ColorVectorSpace v0.9.

[kimikage]

BTW, this may be a matter of preference, but if you push commits to the master branch without creating a PR, we have less chance of noticing problems.

[johnnychen94]

Yes... I was tricked by the CI green check, and yes strictly speaking #955 should be a part of #937.

Images v0.24.0 is the first step to smooth the transition to ColorVectorSpace JuliaImages/ImageCore.jl#157 (comment)

BTW, this may be a matter of preference, but if you push commits to the master branch without creating a PR, we have less chance of noticing problems.

There're tens of packages under JuliaImages that I need to take care of. Without Tim's availability recently, I took the liberty to make the process going faster for things that I'm confident about by directly committing to master without notification. 6acde97 is committed right after #937 so it would be less likely to be an issue. (and yes I was tricked by the CI green check). When the community grows with more active maintainers and contributors involved, I'll slow the process.

It's #937 and not 6acde97 where the incompatible issue comes up. (I believe I ran the test locally once before merging that PR, but I guess I somehow forget to check the versions)

[kimikage]

As for the development style, I think you have the most decision-making power right now.

My point is that Images v0.24.0 has been released to the public, not just to the CI of the downstream packages which you manage. The problem is not in the commit 6acde97, but with the registration.

Generally speaking, the sooner we fix inconsistent state, the better. Of course, there is no issue report up, and I am not going to rush to release the bug fixes. However, with this PR merged in, there is a possibility that the available versions will be deadlocked in v0.24.0.

[johnnychen94]

The reason I haven't make a new patch release yet is that I'm still working on #879 (comment)

[kimikage]

In other words, I am saying that the "lower bound" technique should not be used now. It was effective at the time of the release of v0.24.0.

[johnnychen94]

I guess I'm still not understanding the exact issue you're discussing.

Do you mean we should add back ImageCore 0.8.3, and release Images v0.24.1 with ImageCore compact 0.8.3, 0.9 to at least make sure there's a compatible non-buggy version to patch Images v0.24.0? If so I think it's a good idea.

[kimikage]

That's right. The support for ImageCore v0.9 could come later (e.g. Images v0.24.2), though.