v0.0.25

[thombruce]

Describe your changes here. Mark relevant issues for closure with closes #N.

By submitting this pull request, you agree to follow our Code of Conduct: https://github.com/thombruce/.github/blob/main/CODE_OF_CONDUCT.md

---

Internal use. Do not delete.

• [ ] Tests passing
• [x] Coverage sufficient
• [x] Manual review
• [x] No A11y regression
• [x] Translations provided or not needed

[thombruce]

TODO

• [x] Allow the above tests to pass
• [x] Mark as ready for review (see if the tests are run again - I don't think they will be; we want to change this behaviour: #108)
• [ ] Merge to main
• [ ] Tag release

Is that the right way about this?

My current workflow would have had me making these version-bumping commits directly on main and tagging the commit that bumped the numbers directly, then pushing the changes and tag all at once straight to main.

I'm trying to set up branch protection as a general rule, however, so that we can ensure tests are run for all changes submitted via PRs.

This appears to mean that after the PR is merged, I should pull the changes to my machine, tag the HEAD and push the tag back up - this should trigger the release workflow.

[thombruce]

Test failures concern an inability to compile bevy-inspector-egui, which is not strictly essential (it isn't used in the release build, which is what the CI is attempting to build).

Not sure why it's failing; this exact same build has successfully worked on main for a while...

[thombruce]

Build succeeds locally...

Tempted to go ahead with the merge here to ensure that the tagged release on main still succeeds, as I expect it does. But no, no, don't just expect that...

This is probably a Rust version issue. The Rust version used for the attempted builds here was 1.74. Locally, I am running 1.73.

Recommend we pin the Rust version in the workflows.

[thombruce]

Rust version should now be locked to v1.73.0 in both CI workflows.

For context, I did recently need to upgrade Rust locally with the Bevy v0.12 update. Rust has been updated again since this upgrade, and there are no guarantees that 1.74+ are compatible with the crates I'm using... I think this is the most likely cause of the error here; I'm just surprised that nothing like this came up sooner if that's the case.