-
Notifications
You must be signed in to change notification settings - Fork 201
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
[towards 1.0]: Fallible proven traits #192
Conversation
r? @thejpster (rust_highfive has picked a reviewer for you, use r? to override) |
We agreed on |
16bd944
to
5bc0f0c
Compare
Oops, I misread that. Here some more work towards what was discussed and thus 1.0.
I did not rename the adc::Channel::channel() method. This method exists at all due to rust-lang/rust#54973, which is fixed as of Rust 1.35.
|
Personally I'm OK with upping the MSRV to 1.35. That is now 7 versions (or 42 weeks) behind the current stable. |
I think that adding |
Hmm, this would mean we would be back to Here a relevant excerpt from the meeting protocol:
|
LGTM. Any reason we can't merge this? |
[dependencies.nb] | ||
version = "0.1.1" | ||
[dependencies] | ||
nb = { version = "0.1.1", features = ["unstable"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unstable
? That has a weird sound to it considering that we're aiming to stabilize this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because currently the unproven
feature requires nb/unstable
. The state of the unstable
feature should be discussed for nb
's 1.0 release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the 1 nit I mentioned inline looks good to me.
bors r+ |
Build succeeded |
Sorry to raise this a bit late, but would it make sense for us to batch all the breaking change PRs into a separate branch so that we can release bug fixes (for example #194) prior to the next major release? Adds to workload in keeping the branch up to date but avoids this stalling us if this takes a little while. |
I'm a big fan of git flow for release management, but that didn't go down well in a recent meeting. Shall we put something about rules for branch management on the agenda for the next meeting? |
For now if you need to make a hotfix, I suggest you create a branch from the release tag. |
I agree we should try to keep the individual PRs as compact and self-contained as possible to allow for cherry-picking if necessary for e.g. a bugfix release.
Well, it would be sufficient if the reviewer insisted on broken down PRs before accepting a wholesale crate PR. 😅However in this particular case we're good because the author took good care and split the change into plenty of individual commits. |
Here some work towards 1.0 following #177 (comment).