Skip to content
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

Preperations for release 0.10.2 #797

Closed
wants to merge 1 commit into from
Closed

Preperations for release 0.10.2 #797

wants to merge 1 commit into from

Conversation

9names
Copy link
Member

@9names 9names commented Apr 28, 2024

Update CHANGELOG.md
Set version to 0.10.2 in preparation for the release

This is based on main, not 0.10.x branch.
The only changes from 0.10.1 -> 0.10.2 are the PIO DMA transfer size changes. We think these are not breaking changes, so we're doing 0.10.1 and 0.10.2 as a tactical release strategy - will yank 0.10.2 if this release causes people grief.

See #796 for the changes that were cherry-picked from main for that release.

@jannic
Copy link
Member

jannic commented Apr 28, 2024

I'm in favor of a 0.10.1 release, but I'm not yet convinced if 0.10.2 with the DMA changes should be released, and the git history looks a bit confusing: Why is there a v0.10.x branch containing (the preparations for) 0.10.1, but 0.10.2 is a merge request to the main branch?

IMHO it would be less confusing if we either decided that the DMA changes are actually fine for a 0.10.1 release and release it from the main branch, or accept that the risk of a breaking change is too high, release 0.10.1 from a separate branch, and don't do a 0.10.2 with the DMA changes. But is it important to have an easily understandable git history? Or do we mainly care about the actual releases on crates.io, and it doesn't matter much from what git branch they came?

(Edit: 0.10.1 was released while I was writing this comment. That's fine, thanks for caring about it, 9names! So releasing 0.10.1 from the main branch is no longer possible. Now the open question is if we want a 0.10.2 release with the DMA changes, and if so, if it should be built from the main branch, or if we cherry-pick the changes to the v0.10.x branch?)

@9names
Copy link
Member Author

9names commented Apr 28, 2024

Sorry about that, thought your comments on that branch were also broad approval of the approach.
I did consider pulling these changes into the 0.10.x branch, wasn't sure if that would be better or worse as far as keeping history goes.

If we pull the changes into 0.10.x instead, and then merge that into main to get the changelog updated does that make the git history more or less messy than it would be going this way?

@jannic
Copy link
Member

jannic commented Apr 28, 2024

Don't worry, it doesn't make sense to hold off progress just in case someone might come up with another opinion. And cleanliness of the git history is only a minor detail. Usually, nobody cares.

Still, connecting v0.10.x and main with a merge commit is a good idea. That way, the v0.10.x branch will contain all 0.10.x releases, and we avoid the risk that a later 0.10.3 release accidentally misses the changes from 0.10.2.

About the possibly breaking changes: There are two relevant modifications between 0.10.1 and main:

  • Adding type parameters to Tx and Rx, e.g. pub struct Rx<SM: ValidStateMachine>pub struct Rx<SM: ValidStateMachine, RxSize = Word>
  • Adding the same type parameters to uninit, pub fn uninit(self, rx, tx)pub fn uninit<RxSize, TxSize>(self, rx, tx)

According to https://doc.rust-lang.org/cargo/reference/semver.html#trait-new-parameter-default the first one is fine. And the example from https://doc.rust-lang.org/cargo/reference/semver.html#fn-generic-new where adding a type parameter to a function can be a breaking change doesn't apply here: Previously, uninit didn't have type parameters, so there shouldn't be any existing callers with the wrong number of type parameters. A few quick experiments with examples actually calling uninit didn't show any issues with that update either.

@9names
Copy link
Member Author

9names commented May 3, 2024

Closing this to make room for a bugfix 0.10.2 release

@9names 9names closed this May 3, 2024
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.

3 participants