image-rs
Should the next major release be 1.0?
...with versions 2.0, 3.0, etc. planned for subsequent releases?
The image crate has been doing breaking releases only every 1-2 years at this point. We've been holding off on doing a 1.0 release based on the hope that we'd eventually "finish" and then could stick with a single stable API indefinitely. Honestly, I don't think that's likely to happen for the foreseeable future. The public API surface is just too large, and there's too many edge cases. Not to mention that it would raise the stakes on new feature additions if we couldn't change course when flaws are discovered.
At the same time, I think our current strategy poorly communicates the level of stability we do provide. There's plenty of ecosystem crates that have gone from 1.0 to 2.0 and further, in less time than between our consecutive breaking releases.
So I propose we declare the next release to be 1.0. Based on historical pacing, it would probably come out in 2025. At that point, we'd want to make sure that release messaging was clear that subsequent major releases were planned. But I think that makes more sense than just being pre-1.0 forever.
It might be worth splitting the core types into a separate crate and making that 1.0, while keeping some other stuff under less strict stability guarantees. There is a long-standing proposal for such a split, see #793
Stability of these basic types is especially important now that image deliberately excludes support for certain features, such as libwebp encoding (#1984), JPEG XL decoding/encoding (#1979), or fast image resizing that uses unsafe code (fast_image_resize crate). This requires third-party crates to be tied to specific versions of image in their public API, and bump their semver anytime image is bumped. Having a foundational crate with basic types might result in less churn for the ecosystem.
Are you thinking that the crate with core types would be permanently 1.0 and not make any subsequent breaking changes? That was the original thinking in #793, but after 5+ years we aren't much closer to having final designs for ImageDecoder, ImageBuffer, GenericImage, etc. that we'd be comfortable committing to forever. In fact, skimming the release notes from the last few breaking releases, probably the majority of changes have been to these types/traits.
The consensus seems to be in favor of this, so I'm going to go ahead and close