Bump compatibility for FPN/ColorTypes/Colors

[timholy]

This is a minimal update that gets this working with the latest versions of FixedPointNumbers, ColorTypes, and Colors. I've checked that tests pass without warnings on both ColorTypes 0.9 and ColorTypes 0.10.

Closes #122
Closes #127
Closes #128

[johnnychen94]

It occurs to me that rolling release has real merits to avoid the version resolving issue until Pkg become smart enough, even if there're only compat commits.

[kimikage]

Since the dependencies related to ColorVectorSpace are somewhat irregular, I have no objection to early merging and tagging this PR. 🚀
However, I don't think this is just a matter of the smartness of Pkg. Finding the combinations which work fine, and finding the compatibility issues are ambivalent requirements. Currently, the solution relies on humans' attentiveness, so frequent version changes are not really good.

[johnnychen94]

Currently, the solution relies on humans' attentiveness, so frequent version changes are not really good.

Does bumping a patch version introduces more humans' attentiveness? No, it solves issues and makes people less headache.

However, I don't think this is just a matter of the smartness of Pkg.

Are there really any compatibility issues in PRs like JuliaImages/ImageShow.jl#19, JuliaImages/ImageCore.jl#124 ? No. Version resolving fails because Pkg doesn't handle the interaction between [test] and [deps] sections smartly to downgrade Colors, ColorTypes and FixedPointNumbers to a compatible version; there're such versions as declared in Project.toml.

[kimikage]

Does bumping a patch version introduces more humans' attentiveness?

Does your claim above relate to the patch versions? I think we don't need to hesitate to release a patch version of the latest branch. However, note that whether it is a patch version or a minor version is another matter for compatibility, because:

1. we are still dealing with many packages in v0 series.
2. although SemVer guarantees the interface compatibility, it does not guarantee the behavior compatibility (of dependent packages).
3. we may not strictly follow the SemVer.:sob:

Of course, in "ideal" rolling releases, when such compatibility issues arise, they will be fixed quickly. However, there are clearly not enough developer resources to realize the ideal.

My point is that there is no silver bullet.

[johnnychen94]

However, there are clearly not enough developer resources to realize the ideal.

😞 🤷‍♂️ ❤️

[daschw]

Is there anything holding this and a release back? It would be great to have for Plots tests.

[timholy]

I've been pretty busy lately and perceived some unhappiness about this, but there don't seem to be specific objections so let's do it.