image-rs
1.0
Hi, one of the crates I'd like to use is having trouble keeping up with the new versions and changing API.
https://github.com/abonander/img_hash/issues/23
I'd like to know if there's a tracking issue for 1.0. I see you have some milestones, but I'm not sure what in particular is holding up the drive towards a 1.0 moniker. Any updates on this matter would be appreciated.
It was my mistake originally for releasing a 1.0 of img_hash before my public dependencies had stabilized. However, I am curious what's blocking this crate from reaching its 1.0 since it's been around so long. The public API appears to be relatively stable as I was able to upgrade from 0.13 to 0.19 without any breakages.
@abonander That highly depends on which part of the public api you are using. The utility functions such as transforms, conversions, loading etc. were kept from breaking with newer versions. Meanwhile the main trait has recently been reworked into separate ones and it even has deprecated functions for which an alternative has yet to be found.
Similarly, while loading has been kept stable there has been a development towards allowing additional parameters for image formats.
Overall, I think we should delay 1.0 at least until we have solved the issues of constrained color spaces, and worked out how to deal with en/decoders uniformly. Specifically, DecodingResult and ImageDecoder::read_scanline, ImageDecoder::load_rect should get better support by decoders. Along the same line of action–ImageDecoder::into_frames feels weird in that it does not use the same DecodingResult, is default implemented via an internal method and almost never used by decoders. Should it get moved into separate (auto-)traits for clarity?
Some, but there is still a bunch of the API surface that I think needs improvement before people would be willing to stabilize. At the moment my impression is that myself and the others involved in maintenance/development don't really have the bandwidth to make a big push towards 1.0
