Propose wording for republishing as 0.25.4

[HeroicKatora]

Closes: #2353

I've re-written the change to essentially transfer 0.25.3 to 0.25.4.

The proposed publishing action, in sequence since this is an unusual circumstance:

1. Wait for CI to clear everything apart from the SemVer checks
2. Verify that the Orientation interface is the only linted error in CI
3. Approve the PR
4. Checkout the commit to-be-published
5. Verify the PR is based on the current main branch (otherwise, go back to 1.)
6. Yank the version 0.25.3: cargo yank --version 0.25.3
7. Publish: cargo publish

Please review both the changelog and the list.

[fintelia]

Not sure I completely understand the proposed steps. But since CI is showing green other than the one semver-check issue, the next steps should be:

• Merge this PR (I tend to prefer squash merges, but others seem to like normal merges better)
• Check out the main branch locally with git checkout main
• Verify that the state is as expected by checking git log and cat Cargo.toml
• Publish the new release via cargo publish and yank the previous release via cargo yank --version 0.25.3

[Shnatsel]

Looks good to me! I don't have crates.io publishing rights, so I'll have to ask one of you to actually execute this.

[HeroicKatora]

Ahh! Good that we talked about that. As here the task list calls for publishing the tip of the branch, not the merge. Iirc, the two main considerations were:

• The commit at the tip can be signed ahead-of-time. The automatic merge commit can not. I think I still had hope at the time of crates.io somehow introducing two-factor signing-keys or certs for publish actions sometime soon.
• The race condition of history when the merge diverges from the tip-of-branch as was the case here. Re-considering about that right now makes me realize that this itself would be inconsistent with current CI setup to run on the merge instead of the tip-of-the-branch. And quite apparently it lead to misunderstanding anyways, so it may be better to use the more wide-spread workflow.

I'm slightly torn but it does not seem to matter right now. So please, go ahead, I think your sequence also works. Merge v. Squash should not matter greatly (even less so since bisect --first-parent).

[Shnatsel]

I'd appreciate if one of you could run the yank command on 0.25.3 ASAP. No reason to leave it up for longer than necessary.

I want to get it over with so that we can all take a well-deserved break 😅

[HeroicKatora]

Agreed. I followed @fintelia 's protocol verifying history with a git merge --ff-only when fetching updates.

[Shnatsel]

Sweet, it's all done now! I've also tagged the v0.25.4 version in git (I double-checked what got published to crates.io and tagged the matching commit).

I'm going to post a release announcement to Reddit tomorrow. Here's the draft - no action required, just FYI:

---

image v0.25.4 brings faster WebP decoding, orientation metadata support, fast blur

A new version of image crate has just been released! The highlights of this release are:

• Decoding lossless WebP images 2x to 2.5x faster, thanks to a variety of optimizations done by fintelia
• An approximate but much faster blur implementation was contributed by torfmaster
• Orientation metadata is now supported, so you can easily display smartphone photos with the correct rotation

There are also some bug fixes to decoding animated APNG and WebP images, and other minor improvements.