New version?

[little-arhat]

Hi,

Number of features have been added since 0.2.1 -- should there be another release? I can't use git dependency if I want to publish hal-impl to crates.io.

Are there any guildelines regarding versioning? Seems like any new feature merged to master should bump patch level, otherwise hal-impl can't really use them.

[therealprof]

I agree both with the idea of bumping the version with each change and to have a new release soon.

[little-arhat]

What about releasing new version with revised list of unproven features?

[ryankurte]

I'd like to push a new version once we've landed #101, #102 and #105 (hopefully shortly), which will be an 0.X release (specifically 0.3.0) due to breaking changes, any comments @rust-embedded/hal ?

[therealprof]

@ryankurte Which change is do you see as breaking?

[ryankurte]

The falible digital traits PR (#105) is breaking

[therealprof]

Right, but I was hoping we would release a non-breaking 0.2.2 before pulling that in.

[ryankurte]

Fine by me, we need more reviews on all the linked PRs so once 101 and 102 are reviewed and merged we can release an 0.2.3 then land 105 and 0.3.0.

[hannobraun]

• ADC-related traits #101 is almost ready to go. Waiting for the author to squash commits.
• I still question the wisdom of removing the unproven flag on a trait right before making breaking changes to it, but if you want to merge Remove InputPin unproven flag per #41 #102, I won't stand in the way.
• Make digital traits fallible #105 is blocked by this issue, but otherwise ready to go

[therealprof]

I can see people wanting to stay on 0.2.x until all crates are ready for 0.3 which will take a while and the request to prove traits has been an elephant in the room for quite a while even longer than this ticket which is also is a few months old now.

[hannobraun]

I understand that people want proven traits, but I question the point of declaring traits with known issues proven, then breaking them due to those known issues.

Yes, it sucks that those traits have known issues, and that we have to make breaking changes to fix those known issues. I don't see how declaring those traits proven right before making those breaking changes benefits anyone.

I understand that those users who want the traits proven might stay on 0.2.x for a while. I don't see how not having to enable the unproven feature during this time benefits them. They'll have to fix their implementations when upgrading to 0.3 in any case. Declaring those traits proven will remove a minimal obstacle to using them (enabling a feature) at the cost at confusing people about the future stability of those traits.

But as I said previously: I'm not making a stand here. It's not what I would do, but if you want to merge #102, go ahead.

[therealprof]

I understand that people want proven traits, but I question the point of declaring traits with known issues proven, then breaking them due to those known issues.

I'd like to see that we're sticking to the rules which were once decided (or change them).

Regarding the "issues" and breaking the traits in the next version: When the "digital" traits were conceived they were meant to cover regular GPIOs and operations on those usually can not fail so it didn't make sense to have them fallible. In hindsight it should have been clear that IO expanders and multiplexers exist (especially since people including me have used them in the past) and that someone will eventually come up with a driver.

I am no and (most likely never will be) a fan of replacing the previous digital traits with fallible versions of it under the same name because the old traits are widely used and the fallible ones are really only required for a few new and special use cases. This change will split the whole Rust "full-stack" embedded ecosystem in two and I have serious doubts that it'll quickly recover. This is a huge risk and could potentially cause a lot of harm. Hence I really prefer a separate set of traits which would be non-breaking and allow fallible and non-fallible versions to co-exist (and even better to be used at the same time) and phase out the old traits much later.

[hannobraun]

I understand that people want proven traits, but I question the point of declaring traits with known issues proven, then breaking them due to those known issues.

I'd like to see that we're sticking to the rules which were once decided (or change them).

Let me take a step back here, because I think it's important we're all on the same page:

1. Remove InputPin unproven flag per #41 #102 proposes to mark InputPin proven, with 2 participating team members being in favor, 1 (me) arguing against.
2. In [RFC] Managing breaking changes to existing traits #100, I proposed making the digital trait changes a clean break, which has been met with +1's and no opposition.

The combination of those two things is what I'm arguing against, because I think it makes no sense. But I don't think the combination of these two things is what you're arguing for. You want to go forward with #102, but you don't want to break the digital traits.

Let's revisit my proposal to make the digital changes a clean break. I proposed this because I started feeling bad about that pull request, and didn't want it turning into one of these months-long affairs, where the contributor is changing stuff again and again, due to changing reviews with ever new insights. Due to the response there (+1's, no opposition), I assumed that we'd be doing this.

I think I was wrong in at least one, possibly two ways. First, your comment has almost got me convinced that my proposal was wrong, and that we shouldn't do a clean break here. Second, even if I was right, it was wrong of me to assume we were going with this proposal after just a few days without opposition. I should have given you and others more time to respond.

So, if we won't break the digital traits, #102 makes a lot more sense. The digital traits can become proven (and possibly, at the same time, deprecated), while we go forward with a second set of traits. That's something I can get behind.

The question remains is how exactly we're going to transition (or whether we're going to transition at all). I think you're saying you might want to have two sets of traits in perpetuity, but I think that is not a workable solution, as I've previously explained.

I am no and (most likely never will be) a fan of replacing the previous digital traits with fallible versions of it under the same name because the old traits are widely used and the fallible ones are really only required for a few new and special use cases. This change will split the whole Rust "full-stack" embedded ecosystem in two and I have serious doubts that it'll quickly recover. This is a huge risk and could potentially cause a lot of harm. Hence I really prefer a separate set of traits which would be non-breaking and allow fallible and non-fallible versions to co-exist (and even better to be used at the same time) and phase out the old traits much later.

As I said, I don't think keeping two sets of traits in perpetuity is a workable solution (again, my explanation), but a slow transition phase is perfectly fine. I still think my proposal ([1], [2]), which is possibly the same as your proposal, is the best way to go here. @ryankurte is not convinced, though :)