Incorrect (breaking) semver release for 0.25.7

This happens in 0.25.7 for functions that seem to have been made 'more generic'.

2d106bb

This is a breaking change.

Expected

A new minor version should have been released instead of a patch.

Actual behaviour

A patch release was published and now my usage of that function that previously would accept certain types no longer directly does (requires deref).

Reproduction steps

use std::sync::Arc;
use bytes::Bytes;

let bytes = Arc::new(Bytes::new());

image::load_from_memory(&bytes).unwrap(); // <===== previously worked. now requries `&*bytes`

Hm, this is a bit unfortunate and discussed in RFC1105 for why neither we, nor cargo-semver-checks, thought that to be a major change. Reminds me generally of the chrono breakage from the standard library that was also technically permissible but still very unfortunate and debatable. If we yank we should do so quickly.

Since yanking is easy to undo, I've yanked it for now for breathing room. Certainly, changing it back is also going to break much fewer people as most are still updating. It was introduced in #2470 and unfortunately there's no way to keep the old interface with the improvements as far as I can tell.

FWIW, I don't actually mind making the change in the code affected in my repos. I think the change makes a lot of sense. But I thought it would be good to bring up in case you were unaware, and it definitely feels weird to have to make a code change to upgrade a patch version.

This is actually a case that cargo-semver-checks doesn't yet attempt to detect. And looking back at the original PR, it seems that even one of our tests had to be changed to address it. So unfortunately, I think we'll probably have to revert it and have the performance fix wait for our 1.0 release.

I'm alright with the revert, it's performance and not functionality. Can we brainstorm if there's a way to lint the function use so that people can start to prepare? Not that the revert PR should be dependent on it, just keeping it in mind for the eventual re-introduction.

I'm not sure, but don't #2501 and #2522 also have a potential for breakage? e.g. if it would now cause a lossy pixel format conversion where it wouldn't before, and the program would have relied on save failing on pixel format incompatibiltiy. In #2522 the docs were changed to mention the potential loss of alpha channel or precision, where it wasn't documented before. Does it depend on how the policy about version compatibility around errors is defined?

Navigation Menu

Repository navigation

Incorrect (breaking) semver release for 0.25.7 #2585

Expected

Actual behaviour

Reproduction steps

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Incorrect (breaking) semver release for 0.25.7 #2585

Description

Expected

Actual behaviour

Reproduction steps

Activity

197g commented on Sep 1, 2025

197g commented on Sep 1, 2025

BSteffaniak commented on Sep 1, 2025

fintelia commented on Sep 1, 2025

197g commented on Sep 2, 2025

qwertz19281 commented on Sep 2, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions