oily_png
oily_png copied to clipboard
wvanbergen
Allow using current oily_png with current chunky_png
The current chunky_png version is 1.4.0. A dependency ~>1.3.0 will not allow 1.4.x, only 1.3.x. The comma is a logical AND (&&).
@wvanbergen Is the current oily_png compatible with chunky_png 1.4.0?
@donv You're right! I i didn't realise chunky was already at 1.4.
But '~> 1.3', '>= 1.3.7' would still allow versions < 2.0 to fill the dependency. That might be reasonable or it could be made '< 1.5', '>= 1.3.7' to follow the current convention of specifying one allowed minor release at a time.
Semver dependencies usually allow updating to new minor versions, but i don't feel strongly about this as long as we can use 1.4.x at least.
ChunkyPNG 1.4.0 includes a larg change in how ChunkyPNG::Palette is implemented to account for Ruby 3.0 changes.
Semantic versioning is a bit tough with OilyPNG, because OilyPNG needs to exactly reimplement ChunkyPNG, even methods that are not part of the public API. OilyPNG doesn't implement Palette, so it should work with ChunkyPNG 1.4.0 as is. It would be great if somebody could verify this before I release a new version of OilyPNG.
It would be great if somebody could verify this before I release a new version of OilyPNG.
This branch worked perfectly fine for me when I tested an implementation for some generation benchmarks.
PS: The qr code generation was with oily_png still much(!) slower in comparison to a Go implementation (divan's qrlogo), though. :disappointed:
I also tried image.save(path, :fast_rgb) (resulting in much bigger files) but the speed difference was not very huge (278s vs 264s for 400 QR codes). Maybe it's rqrcode, what's making it slow.
It would be great if somebody could verify this before I release a new version of OilyPNG.
We are testing this over at https://github.com/donv/capybara-screenshot-diff , and all our tests are green.
That should be two projects at least that work with the new version. Is this sufficient to release a new version?