Version 0.26.x

[fintelia]

Tracking issue for items to consider for the 0.26 major version. One lesson from the prior release is that it is much easier if we have PRs ready before the release window starts.

Planned

(none yet)

Possible

• Remove encode method on other encoders (in because it is redundant with ImageEncoder::write_image)
• Pixel access changes:
  • Pixel access naming conventions #1853
• Remove more deprecated methods:
  • Pixel::{channels4, from_channels}
  • GenericImage::{get_pixel_mut, blend_pixel}
• Remove GenericImage<Pixel = Rgba<u8>> implementation for DynamicImage
  • Prevent confusion like in GenericImage::copy_from can't be used with RGB, only with RGBa #1952
  • Remove GenericImage<Pixel = Rgba<u8>> impl for DynamicImage #2136
  • DynamicImage:from SubImage<&DynamicImage>::to_image creates Rgba8 instead of L16 #2274
• Remove PngDecoder::with_limits and fix PngDecoder::set_limits
  • PngDecoder supports setting limits via with_limits but not via set_limits #2084
• Rename Reader to ImageReader
  • Rename Reader to ImageReader #2243
• Update API for crop
  • The documentation on crop() is confusing #2293
  • Cropping API doesn't check bounds, easy to misuse #2296

[ripytide]

In #2243 you mentioned not making breaking changes to the main branch in case patch releases are needed, but leaving them as open PRs risks merge conflicts. How about we make a branch upon every release which can be used for making patch releases and then the default branch can be used as the "dev" branch including breaking changes?

[fintelia]

@ripytide I should probably give more context on image's release strategy...

This crate has been around for a very long time. I joined much later, but the crate actually started before Rust 1.0 and even before crates.io itself. Given the age it would make sense for us to have hit 1.0 and completely stabilized the API. However, that never happened. By the time I came on as a maintainer the sprawling scope of the public API and many lingering design questions were pretty daunting. At one point I tried spinning off part of the interface into its own image-core crate to get that portion to 1.0 but that didn't pan out because the design didn't actually let us iterate the API.

Instead, we've adopted the approach of treating each minor release as long-lived. The 0.22 series lasted a year, 0.23 lasted two years, and 0.24 lasted two more years. This strategy lets us make breaking changes when we identify better ways of doing something, while still providing stability. And that stability is evidently important given how slowly users upgrade: about two thirds of users still haven't upgraded to 0.25 several months after release. And we still get over 100,000 downloads/month of the 0.23 series that last released in early 2021!

Accordingly, we're still extremely early into the 0.25 series. Any new feature development should happen there for the foreseeable future

[fintelia]

To address the specific question of branching strategy, what we've done in the past is to fork off a next branch shortly before the new release. Since major releases contain only API changes with minimal new feature development, changes can be merged quickly and there isn't much time for the two branches to diverge. The release concludes with next merging back into main.

[HeroicKatora]

Since #2239 is breaking on the Pixel trait but otherwise the surface is quite small, would be great to decide on it, and imo land, it in 0.26.

[Shnatsel]

A few more issues fixing which would require an API break:
#2293
#2274
#2296