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
  • #2506
• [ ] Remove GenericImage<Pixel = Rgba<u8>> implementation for DynamicImage
  • Prevent confusion like in #1952
  • #2136
  • #2274
  • #1592
• [x] Rename Reader to ImageReader
  • #2243
• [ ] Change blur to take the blur radius rather than sigma
  • #2508
• [x] Color space support
  • #2531
• Various API consistencies
  • #1384
  • #1201
• [ ] Better configure underlying format encoders with the ImageEncoder trait
  • #2084
• [ ] Polishing for ImageDecoder
  • [ ] Remove PngDecoder::with_limits and fix PngDecoder::set_limits
  • [ ] Some PNG structure can not be used #2652
  • [ ] jpeg always allocates as a result of the interface
• Remove accidentally added ImageFormat::Pcx variant
• Make rayon an explicit feature, not a default feature
  • #2028
• Replace DynamicImage::resize with DynamicImage::resize_proportional (or similar) to make behavior clearer.
  • #2645

Possible

• [ ] Remove encode method on other encoders (in because it is redundant with ImageEncoder::write_image)

  • [x] jpeg #2636

• [ ] Pixel access changes:

  • get_pixel is very inconsistent and should be Option, mostly: #1853
  • row iteration could yield standard slices: #2113

• [ ] Update API for crop

  • #2293
  • #2296
  • #1201

• [ ] Remove more deprecated methods:

  • Pixel::{channels4, from_channels}
  • GenericImage::{get_pixel_mut, blend_pixel}

• [ ] Support no_std

  • #1184
  • #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 https://github.com/image-rs/image/pull/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: https://github.com/image-rs/image/issues/2293 https://github.com/image-rs/image/issues/2274 https://github.com/image-rs/image/issues/2296