Version 1.0 plan

[fintelia]

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

Rational for going to 1.0 is described in #2316. Notably, this is not intended as the last breaking release, only as an indication of the crate's existing commitment to stability.

Planned

• Change default speed parameter for GifEncoder
  • GIF encoding has a poor speed default #2506
• 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
  • impl GenericImage for DynamicImage looses precision #1592
• Rename Reader to ImageReader
  • Rename Reader to ImageReader #2243
• Change blur to take the blur radius rather than sigma
  • Confusing Gaussian blur API #2508
• Color space support
  • Implement Cicp for ImageBuffer,DynamicImage and provide ColorTransform on moxcms #2531
• Various API consistencies
  • Please Make 16 Bit Types accessible outside of the crate! #1384
  • Tracking: imageops:: and DynImage::crop()/crop_imm() breakage #1201
• Remove accidentally added ImageFormat::Pcx variant
• Make rayon an explicit feature, not a default feature
  • Rayon should not be available as default feature #2028

Possible

• Remove encode method on other encoders (in because it is redundant with ImageEncoder::write_image)
• Pixel access changes:
  • get_pixel is very inconsistent and should be Option, mostly: Pixel access naming conventions #1853
  • row iteration could yield standard slices: Add par_enumerate_rows(_mut) to ImageBuffer and friends #2113
• Remove more deprecated methods:
  • Pixel::{channels4, from_channels}
  • GenericImage::{get_pixel_mut, blend_pixel}
• Remove PngDecoder::with_limits and fix PngDecoder::set_limits
  • PngDecoder supports setting limits via with_limits but not via set_limits #2084
• Update API for crop
  • The documentation on crop() is confusing #2293
  • Cropping API doesn't check bounds, easy to misuse #2296
  • Tracking: imageops:: and DynImage::crop()/crop_imm() breakage #1201
• Support no_std
  • no_std support #1184
  • Add no_std Support #2462
• Default limits matching Limits::default

[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.

[197g]

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