Skip to content

Prepare release 0.9.1 #574

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 20, 2025
Merged

Prepare release 0.9.1 #574

merged 1 commit into from
Aug 20, 2025

Conversation

sosthene-nitrokey
Copy link
Contributor

@sosthene-nitrokey sosthene-nitrokey commented Apr 29, 2025

@therealprof
Copy link
Contributor

@sosthene-nitrokey I don't think we should block this on #571 and just get it merged.

@sosthene-nitrokey
Copy link
Contributor Author

sosthene-nitrokey commented Jul 30, 2025

#571 is not a "blocker" but I'd rather do the breaking change before releasing (especially given that the PR has been reviewed and is only one nitpick being resolved away from being merged) rather than #571 ending up being blocked forever on a new breaking release to be merged.

I reworded the pr description to remove the "blocked on", if you judge #571 should be ignored.

@therealprof
Copy link
Contributor

I'd put it the other way around. People are eagerly waiting for a release and #571 is standing in the way of the release. We don't have any limit on the number of releases we can cut, so to me it doesn't make much sense to wait until #571 is ready.

@sosthene-nitrokey
Copy link
Contributor Author

That makes sense to me. On the other hand I personally find it a bit frustrating that I initially made the View PRs in a way that they would be backwards compatible for a 0.8.1 release, and documented the breaking changes I wanted to do in #494 for a next release, but 0.8.1 was never released, and when it was decided to go for 0.9.0 the desired breaking changes were ignored.

I don't say that to justify that my PR should be merged, but to explain why I wanted those breaking changes included before the next release. I understand that maintainer bandwidth can be scarce so it makes sense to not prioritize small ergonomic improvements over releasing what's already there, so if you want to release 0.9.0 as-is it's fine by me.

@zeenix
Copy link
Contributor

zeenix commented Aug 19, 2025

@sgued I think we're ready to release? I hope we have the rights to push releases. :) Could you rebase so the we merge it and push to crates.io and push the tag here?

@sgued
Copy link
Contributor

sgued commented Aug 19, 2025

Yup, I planned to bring it up in the meeting this evening.

@@ -5,7 +5,7 @@ All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](http://keepachangelog.com/)
and this project adheres to [Semantic Versioning](http://semver.org/).

## [Unreleased]
## [v0.9.1] - 2025-08-19
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say the same to you here, what I was told for 0.9.0. :)

Copy link
Contributor

@zeenix zeenix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM otherwise.

This is a breaking change, 0.9.0 should be yanked. See
rust-embedded#568
@sgued sgued added this pull request to the merge queue Aug 20, 2025
Merged via the queue into rust-embedded:main with commit 1918822 Aug 20, 2025
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants