Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<explore>
how is every1?
explore has left #rust-embedded [#rust-embedded]
causal has joined #rust-embedded
Darius has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
emerent has quit [Ping timeout: 264 seconds]
emerent has joined #rust-embedded
causal has quit [Quit: WeeChat 3.7.1]
Lumpio- has quit [Ping timeout: 248 seconds]
Lumpio- has joined #rust-embedded
<re_irc>
< (@hegza:matrix.org)> I maybe miss the meeting, but we think we have a working implementation for using svdtools with SVDs containing clusters (https://github.com/stm32-rs/svdtools/issues/131). We're making some test cases and will get back to you with a PR if it looks consistent.
<re_irc>
< (@adamgreig:matrix.org)> hi room , meeting time again! agenda is https://hackmd.io/31W317hdQW29lDhdk8qfqw?edit, please add anything you'd like to announce or discuss and we'll kick off in 3min or so
<re_irc>
< (@therealprof:matrix.org)> Hm, what was that weird lag just now? 🤔
<re_irc>
< (@adamgreig:matrix.org)> for mastodon it sounds like hachyderm.io is the popular choice, but we'll still want to work out some guidelines on how to run it and keep it consistent with twitter and cohost, i'll try and write up some thoughts on the issue thread but please leave a comment if you have any thoughts there
<re_irc>
< (@adamgreig:matrix.org)> last week we talked about yanking critical-section 0.2.* but it's since come to light that it's actually used by more crates than it seemed through a dependency on an old version of atomic-polyfill, especially in heapless
<re_irc>
< (@adamgreig:matrix.org)> so yanking might break more builds than we want, leading to an alternative in https://github.com/rust-embedded/critical-section/pull/31 where we have a new 0.2 release that uses v1.1 internally instead
<re_irc>
< (@adamgreig:matrix.org)> is that about right ?
<re_irc>
< (@adamgreig:matrix.org)> I dunno if we'd need to yank earlier 0.2 releases at that point, since it won't stop people using them until they go to update, at which point they should end up on a newer point release anyway?
<re_irc>
< (@jannic:matrix.org)> I didn't have much time to do actual testing with that version. But for the things I tried out, it seems to work well. Yes, exactly as you described it.
<re_irc>
< (@jannic:matrix.org)> Not sure about yanking, does it somehow make cargo trigger an update if there is an existing Cargo.lock with the old version?
<re_irc>
< (@adamgreig:matrix.org)> cargo only checks for yanks when locking dependencies, where _usually_ it would then update to the new semver-compat version unless someone had specified =0.2.7 or whatever
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
< (@adamgreig:matrix.org)> it's possible someone does have that, and yanking would help discourage using it I guess? I don't think it will make much difference either way
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@jannic:matrix.org)> If the actual critical section implementation with c-s 1.1 uses a RestoreToken which is smaller or equal to an u8, c-s 0.2.8 would just use the new implementation internally. This doesn't work if the RestoreToken is larger, in which case compiling would fail. So it's a breaking change in a minor release. But not worse than just yanking.
<re_irc>
< (@adamgreig:matrix.org)> do we know of any cases where the restoretoken is larger? most people would have probably been using the built-in one that was u8 i guess?
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
< (@jannic:matrix.org)> In fact I have no idea why one could need a larger restore token.
<re_irc>
< (@jannic:matrix.org)> Perhaps to store a pointer for some reason? But no, I don't know a single implementation which uses that.
starblue has quit [Read error: Connection reset by peer]
<re_irc>
< (@adamgreig:matrix.org)> hopefully pretty low impact then
<re_irc>
< (@adamgreig:matrix.org)> thanks for putting the pr together! is there anything left to do?
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@jannic:matrix.org)> dirbaio obviously had a look at the PR because he gave some feedback. but there has not been any formal review yet.
<re_irc>
< (@therealprof:matrix.org)> "formal" 😄
<re_irc>
< (@jannic:matrix.org)> :-) yes. Perhaps because he didn't want to approve it because he co-authored it?
<re_irc>
< (@jannic:matrix.org)> -because
<re_irc>
< (@dirbaio:matrix.org)> the code changes LGTM after the latest changes
<re_irc>
< (@dirbaio:matrix.org)> I didn't merge because it wasn't clear we were going to go with this route
<re_irc>
< (@dirbaio:matrix.org)> since releasing intentionally-breaking changes in a minor release is controversial
<re_irc>
< (@jannic:matrix.org)> If there's an agreement that it's the way to go, from my side it's good to go.
<re_irc>
< (@dirbaio:matrix.org)> I wanted to wait for this meeting :)
<re_irc>
< (@adamgreig:matrix.org)> I think given as using 0.2 today is most likely a mistake, 1.0's been out a while, and the break is only if you're using restoretoken >u8 which afawk no one is, it's unlikely to impact anyone?
<re_irc>
< (@adamgreig:matrix.org)> if we do release it and get reports of breakage, we could still yank it and just leave 0.2 as-is and hope people move to 1.0 by themselves
<re_irc>
< (@mabez:matrix.org)> : Our Xtensa cs impl uses 32bit tokens to store processor state.
<re_irc>
< (@dirbaio:matrix.org)> : braek is if you're using a builtin impl
<re_irc>
< (@adamgreig:matrix.org)> with an impl for c-s 0.2?
<re_irc>
< (@dirbaio:matrix.org)> because those are removed
<re_irc>
< (@9names:matrix.org)> Did that exist for 0.2?
<re_irc>
< (@adamgreig:matrix.org)> : ah, because you won't have specified a 1.0 impl and it can't specify one for you? right
<re_irc>
< (@adamgreig:matrix.org)> so in fact probably many 0.2 users would immediately get broken builds until they enable an impl?
<re_irc>
< (@dirbaio:matrix.org)> yes
<re_irc>
< (@dirbaio:matrix.org)> but
<re_irc>
< (@dirbaio:matrix.org)> only if you're actually calling it
<re_irc>
< (@dirbaio:matrix.org)> for exaple in the "heapless -> atomic-polyfill -> critical-section" case, it'll still build if you're building for a target with native atomics, because atomic-polyfill will not use c-s
<re_irc>
< (@jannic:matrix.org)> Still not worse than just yanking it. Is there any architecture where the fix isn't easy? (Like, adding a dependency to some default implementation?)
<re_irc>
< (@dirbaio:matrix.org)> or it'll still build if you stick to the heapless parts that don't use atomic-polyfill (only the fancy lockfree queues use it, the "normal" Vec/String doesn't)
<re_irc>
< (@dirbaio:matrix.org)> the reasoning is it's strictly less breaking than yanking
<re_irc>
< (@dirbaio:matrix.org)> especially for people that don't know they're depending on c-s
<re_irc>
< (@dirbaio:matrix.org)> like people using heapless on std
<re_irc>
< (@adamgreig:matrix.org)> so this seems better than yanking it and breaking those builds completely
<re_irc>
< (@adamgreig:matrix.org)> and has the advantage that people using heapless and wanting atomics can now get them with c-s 1.0 too
<re_irc>
< (@ryankurte:matrix.org)> there's a transient dependency via "bytes" too iirc... ask me how i know...
<re_irc>
(this is not in any way opposition to yanking)
<re_irc>
< (@dirbaio:matrix.org)> via "bytes"? :o
<re_irc>
< (@adamgreig:matrix.org)> h...how?
<re_irc>
< (@ryankurte:matrix.org)> oh maybe that's a requirement rather than a dependency
<re_irc>
< (@adamgreig:matrix.org)> the other option is to do nothing and leave 0.2 alone and hope people migrate off it, or possibly a combination of getting heapless onto 1.0 and then yanking 0.2 once it doesn't have as many users
<re_irc>
< (@ryankurte:matrix.org)> * dependency, i'll put digging into wtf i ran into on the list
<re_irc>
< (@9names:matrix.org)> Have we seen folks in the wild get stung by this yet (besides dirbaio)?
<re_irc>
< (@dirbaio:matrix.org)> not afaik..?
<re_irc>
< (@dirbaio:matrix.org)> but using 0.2 usually manifests as "silently unsound" though
<re_irc>
< (@dirbaio:matrix.org)> no build failure, no crash, just silently using the default impl which doesn't do the right thing (like, it's a noop if running in non-supervisor mode)
<re_irc>
< (@dirbaio:matrix.org)> * unprivileged
<re_irc>
< (@dirbaio:matrix.org)> or inter-core memory races on multicores
<re_irc>
< (@newam:matrix.org)> You could make a rustsec entry for using version 0.2
<re_irc>
< (@dirbaio:matrix.org)> the softdevice is pretty much the only case where it manifests visibly, the softdevice throwing assertion failures
<re_irc>
< (@newam:matrix.org)> "cargo audit" failing gets a lot of people to migrate
<re_irc>
< (@jamesmunns:beeper.com)> : IMO this is always my favorite suggestion, just release new versions, come up with fancy solutions if someone ever asks for it
<re_irc>
< (@ryankurte:matrix.org)> would a 0.2.x with everything marked "#[deprecated()]" help?
<re_irc>
< (@dirbaio:matrix.org)> : I asked for it 😅
<re_irc>
< (@jamesmunns:beeper.com)> Ah, fair :D
<re_irc>
< (@dirbaio:matrix.org)> would've saved me 1 day of debugging
<re_irc>
< (@jannic:matrix.org)> And you knew about critical-section. Imagine the same happens to someone who never interacted with that crate.
<re_irc>
< (@dirbaio:matrix.org)> exactly...
<re_irc>
< (@dirbaio:matrix.org)> I wrote the very thing we want to yank 🤣
<re_irc>
< (@jamesmunns:beeper.com)> Publish new version that consists of only a single "compiler_error!()" line ("/s")
<re_irc>
< (@jamesmunns:beeper.com)> "if you don't like this go back and pin the next-oldest version or consider updating to 1.0" :p
<re_irc>
< (@adamgreig:matrix.org)> would "deprecated" warnings show up for people using it through atomic-polyfill through heapless?
<re_irc>
< (@dirbaio:matrix.org)> wants to watch the world burn 🔥
<re_irc>
< (@jamesmunns:beeper.com)> might be _mildly_ less annoying than yanking, since at least you can pin the dep :/
<re_irc>
< (@jamesmunns:beeper.com)> : warnings for deps are silenced iirc
<re_irc>
< (@jamesmunns:beeper.com)> (for published deps, at least)
<re_irc>
< (@adamgreig:matrix.org)> yea, i thought it was something like that, shame
<re_irc>
< (@adamgreig:matrix.org)> add a build.rs that prints a warning to the console 😆
<re_irc>
< (@dirbaio:matrix.org)> you can pin the dep to yanked versions too
<re_irc>
< (@dirbaio:matrix.org)> if you keep the Cargo.lock around
<re_irc>
< (@dirbaio:matrix.org)> or if you add it manually to it
<re_irc>
< (@adamgreig:matrix.org)> not if you then ever want to update the lockfile though right?
<re_irc>
< (@adamgreig:matrix.org)> like you can't put "=0.2.pinned" in cargo.toml, and any cargo update will fail once it's yanked iirc
<re_irc>
< (@jannic:matrix.org)> What about an 0.2.8 with the proposed patch, and not yanking 0.2.7? Then it would be trivial to pin the old version if necessary.
<re_irc>
< (@adamgreig:matrix.org)> would it help to get a new heapless release with a newer atomic-polyfill to hopefully get most people off c-s 0.2?
<re_irc>
< (@dirbaio:matrix.org)> then you just update to c-s 0.2.8 and add an impl for c-s 1.0..
<re_irc>
< (@adamgreig:matrix.org)> sure, once you're doing something to update it's ok
<re_irc>
< (@dirbaio:matrix.org)> : I thought about that too, but it's also breaking (because 0.2 has the default impls, and 1.0 doesn't)
<re_irc>
< (@jannic:matrix.org)> It is breaking but the fix/workaround is easy.
<re_irc>
< (@dirbaio:matrix.org)> it's equally breaking as 's PR
<re_irc>
< (@dirbaio:matrix.org)> and fix if you get broken is equally easy
<re_irc>
< (@dirbaio:matrix.org)> (update, or add a cs1.0 impl)
<re_irc>
< (@adamgreig:matrix.org)> hmm, does that mean atomic-polyfill had a breaking semver-compat release when it updated?
<re_irc>
< (@adamgreig:matrix.org)> ah no I see, it changed at 1.0
<re_irc>
< (@jannic:matrix.org)> A new heapless release would be great in any case.
<re_irc>
< (@dirbaio:matrix.org)> no, it got bumped 0.1 -> 1.0
<re_irc>
< (@adamgreig:matrix.org)> so heapless would have to bump to atomic-polyfill 1.0 and that's technically a breaking change for heapless users
<re_irc>
< (@dirbaio:matrix.org)> yep
<re_irc>
< (@newam:matrix.org)> heapless is still pre-1.0, shouldn't be too bad.
<re_irc>
< (@adamgreig:matrix.org)> big ask for heapless to do a semver-incompat bump in exchange for basically nothing except a dependency-of-a-dependency bumped though
<re_irc>
< (@dirbaio:matrix.org)> but.. BUT
<re_irc>
< (@dirbaio:matrix.org)> if we do the breaking change for them
<re_irc>
< (@adamgreig:matrix.org)> 266 reverse deps of heapless that will have incompat types lol
<re_irc>
< (@ryankurte:matrix.org)> so what's the particular decision that needs to be taken here? new release is fixing / breaking / happening, question is whether to yank / how to bump older deps?
<re_irc>
< (@dirbaio:matrix.org)> then heapless can update atomic-polyfill 0.1 -> 1.0 in a minor release
<re_irc>
< (@adamgreig:matrix.org)> any idea how many people are using custom impls with c-s 0.2 and would hit a break on the proposed 0.2.8?
<re_irc>
< (@adamgreig:matrix.org)> * the built-in
<re_irc>
< (@dirbaio:matrix.org)> because everything will be broken anyway! 🙈
<re_irc>
< (@jannic:matrix.org)> It that pre/post-1.0 distinction really meaningful? Heapless is very popular, I think that's more important than the version number.
<re_irc>
< (@dirbaio:matrix.org)> atomic-polyfill 0.1 and 1.0 are otherwise identical
<re_irc>
< (@dirbaio:matrix.org)> changing c-s 0.2 -> 1.0 is breaking because it removes the builtin impls
<re_irc>
< (@dirbaio:matrix.org)> therefore, so is changing atomic-polyfill 0.1 -> 1.0
<re_irc>
< (@dirbaio:matrix.org)> : dunno how to estimate it... with crates.io had download stats per target or something but no
<re_irc>
< (@jamesmunns:beeper.com)> _galaxy brain_ split heapless into one crate per data structure so we don't need to have breaking changes for people who aren't using atomic'y things
<re_irc>
< (@dirbaio:matrix.org)> : you'll only get the break if you _use_ the heapless atomicy things
<re_irc>
< (@grantm11235:matrix.org)> : You are still thinking too small. Put "heapless::Vec" in "core"
<re_irc>
< (@dirbaio:matrix.org)> so we're good on that end
<re_irc>
< (@adamgreig:matrix.org)> heapless doesn't expose atomic-polyfill as a public re-export either, so the only break if it bumps to 1.0 is the no-default-impl
<re_irc>
< (@adamgreig:matrix.org)> so yea, if you release c-s 0.2.8 which breaks if you don't have a default impl
<re_irc>
< (@adamgreig:matrix.org)> then heapless may as well go ahead and swap to a-p 1.0
<re_irc>
< (@jamesmunns:beeper.com)> (I'm not actually helpful here, will stop making pithy replies)
<re_irc>
< (@dirbaio:matrix.org)> I think the vast majority of affected people will be either
<re_irc>
- using defmt-rtt 0.3
<re_irc>
- using heapless stuff that requires atomic CAS on thumbv6m
<re_irc>
< (@dirbaio:matrix.org)> these are the only popular crates that have ended up depending on cs0.2 AFAIK
<re_irc>
< (@adamgreig:matrix.org)> and defmt-rtt 0.4 has been out a little while now
<re_irc>
< (@dirbaio:matrix.org)> there's lots of example code still on 0.3
<re_irc>
< (@dirbaio:matrix.org)> I just realized all embassy examples are on 0.3 for example
<re_irc>
< (@dirbaio:matrix.org)> :D
<re_irc>
< (@adamgreig:matrix.org)> is there any way to give useful error messages to users of 0.2.8 who get a break due to no impl?
<re_irc>
< (@dirbaio:matrix.org)> another option is to change "atomic-polyfill 0.1" to use "critical-section 1.0", then simply yank all c-s 0.2.x as originally planned
<re_irc>
< (@dirbaio:matrix.org)> : no... you get "undefined reference" linker errors :(
<re_irc>
< (@dirbaio:matrix.org)> "atomic-polyfill" is not a WG crate, it's mine 🤔😈
<re_irc>
< (@jannic:matrix.org)> Would break in the same way if you don't provide an implementation.
<re_irc>
< (@dirbaio:matrix.org)> might be a way out if the WG is not comfortable doing controversial things
<re_irc>
< (@adamgreig:matrix.org)> not worried about the responsbility-laundering as such
<re_irc>
< (@adamgreig:matrix.org)> but it would work around heapless having to do a new release
<re_irc>
< (@adamgreig:matrix.org)> does defmt-rtt 0.3 also bring in c-s via a-p?
<re_irc>
< (@dirbaio:matrix.org)> because I think "yanked due to unsound" is less controversial than "released a weird minor release that tries to semver-trick the impl on top of 1.0 but only for some cases"
<re_irc>
< (@dirbaio:matrix.org)> : no, that's direct
<re_irc>
< (@adamgreig:matrix.org)> if we can stick the exact error message into the c-s docs or github readme or an issue or something, a google search should hopefully pick it up fairly soon
<re_irc>
< (@dirbaio:matrix.org)> yeah... I tried to make that googleable
<re_irc>
< (@dirbaio:matrix.org)> I've seen people fail to google it though
<re_irc>
< (@adamgreig:matrix.org)> so if you try using defmt-rtt 0.3 it would fail to build (because all 0.2 yanked), and you update it to 0.4 (and enable a c-s impl if you haven't already) and then it works
<re_irc>
< (@adamgreig:matrix.org)> and heapless users don't notice anything unless they were using atomics in which case they now need to enable an impl
<re_irc>
< (@adamgreig:matrix.org)> what do you think about a new a-p 0.1 that uses c-s 1.0 for a few weeks, see if anyone gets in trouble, and then yank c-s 0.2 after that, maybe in jan?
<re_irc>
< (@adamgreig:matrix.org)> if it does go wrong you could always yank the new a-p 0.1 to unbreak those builds
<re_irc>
< (@dirbaio:matrix.org)> so, options are:
<re_irc>
<brxken128> : would just like to thank you for the help with "mipidsi" this morning, and also apologise given how stupid my mistake was. cheers for making the awesome crate 🙏
<re_irc>
< (@dirbaio:matrix.org)> --
<re_irc>
< (@dirbaio:matrix.org)> so, options are:
<re_irc>
< (@dirbaio:matrix.org)> I guess once the c-s hack is out, then the atomic-polyfill change is not breaking anymore :D
<re_irc>
< (@dirbaio:matrix.org)> so no reason to not do it
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@dirbaio:matrix.org)> so, 4 it is?
<re_irc>
< (@adamgreig:matrix.org)> I'm leaning towards that? at least provisionally, we can yank c-s 0.2.8 if it causes real problems
<re_irc>
< (@adamgreig:matrix.org)> I don't know if there's any real point yanking older 0.2.x once 0.2.8 is out, but perhaps not a problem to do so either
<re_irc>
< (@adamgreig:matrix.org)> can't wait for some new very popular crate to come out with a pinned dep on =0.2.8 lol
<re_irc>
< (@dirbaio:matrix.org)> well, the whole point was yanking 0.2.x because unsound
<re_irc>
< (@dirbaio:matrix.org)> so imo we should do that
<re_irc>
< (@adamgreig:matrix.org)> yea, OK
<re_irc>
< (@adamgreig:matrix.org)> unless anyone specifically has an objection I think let's go with 4
<re_irc>
< (@adamgreig:matrix.org)> if it does cause problems for someone it seems there should always be a pretty straightforward resolution
<re_irc>
< (@adamgreig:matrix.org)> maybe the c-s 0.2.8 readme can have a clear note about this situation
<re_irc>
< (@adamgreig:matrix.org)> so at least it's on crates.io and docs.rs for people looking at that version...
<re_irc>
< (@adamgreig:matrix.org)> ok, so be it! we're well overtime for this meeting anyway
<re_irc>
< (@adamgreig:matrix.org)> thanks all
<re_irc>
< (@ryankurte:matrix.org)> hey unrelatedly, did we deliberately remove (or never have?) a blocking(*) e-h::serial::Read ?
<re_irc>
< (@eldruin:matrix.org)> it's still there under e-h::serial
<re_irc>
<Limeth> Hello! I have already asked about this in the Rust Community Discord server, but just to make sure I don't try to reinvent the wheel;
<re_irc>
> I am making a driver for an I2C-based controller, which is configured by writing to its registers. Which makes me wonder, is there any solution to simplify this process of representing the register map in Rust? It seems like the svd2rust crate does something like this, but I don't have an SVD file, and don't know of any format used of expressing this information.
<re_irc>
< (@ryankurte:matrix.org)> : right nb is all byte-oriented tho eh? i remember much discussion about the appropriate behaviour of a blocking read but thought we'd landed one for some reason
<re_irc>
< (@dirbaio:matrix.org)> same applies to blocking read (the async trait is just the blocking trait with "async" :P)
<re_irc>
<Limeth> : I didn't know about this crate, it looks very useful. Though I could imagine a macro that would generate a bitfield type for each register, with a constant size and an address as an associated constant. 👀
<re_irc>
< (@ryankurte:matrix.org)> i always though it'd be neat to have some schema then use codegen so you could have one set of register definitions used across languages but, it's never quite been worth it
<re_irc>
<Limeth> It might be challenging to generalize properly. For example, I wouldn't have thought that one would need to be able to express registers with different sizes within a single memory chip ("type Word" in your case).
<re_irc>
<Riccardo Persello> Limeth: Is it an AFE4404? If so, I made a support crate that generates the bitfields from a manually created definition file.
<re_irc>
I think you'd really need a lot of high-register-count devices to really benefit from something like this, but most devices don't really store much.
<re_irc>
<Limeth> Riccardo Persello: It is!
<re_irc>
<Riccardo Persello> Have a look at my implementation here, if you want. Keep in mind that my colleague is refactoring it right now, so its api might change a bit
<re_irc>
<Limeth> How lucky you happened to have read my message, I looked for crates for the AFE4404 and couldn't find anything that looked mature enough.
<re_irc>
<Riccardo Persello> We haven’t published it yet because it’s not fully documented, but we will in a matter of weeks
<re_irc>
< (@dirbaio:matrix.org)> critical-section v0.2.8 now out
<re_irc>
< (@dirbaio:matrix.org)> shall we yank older v0.2.x now, or wait?
<re_irc>
< (@wateryevents:matrix.org)> i would say hold off ripping off the bandaid, but anyway to just archive it anyway? and leave it to devs that wanna work on it to keep it alive or fork it?? or am i miss the function?
<re_irc>
< (@wateryevents:matrix.org)> sorry i just jumped into something i didnt read up on
<re_irc>
< (@adamgreig:matrix.org)> : Let's wait until the meeting next week and check we haven't had any reports of problems, and if not then yank them then?
<re_irc>
< (@dirbaio:matrix.org)> 👍️
<re_irc>
< (@jannic:matrix.org)> LOL it breaks rp2040-hal, because that tries to custom-implement both c-s 0.2 and c-s 1, and those are now the same:
<re_irc>
Why didn't that happen when I tried it by patching the 0.2.7 dependency?
<re_irc>
error[E0428]: the name `_critical_section_1_0_acquire` is defined multiple times
<re_irc>
< (@dirbaio:matrix.org)> oh oops
<re_irc>
< (@dirbaio:matrix.org)> patch release with "critical-section = "=0.2.8"" dep, and remove the explicit 0.2 impl?
<re_irc>
< (@jannic:matrix.org)> Sounds good.
<re_irc>
< (@dirbaio:matrix.org)> but yea I don't think we thought about this case at all
<re_irc>
< (@dirbaio:matrix.org)> where a project is supplying both 0.2 and 1.0 impls
<re_irc>
< (@adamgreig:matrix.org)> : Just normal 0.2.8 would be fine surely?
<re_irc>
< (@dirbaio:matrix.org)> ah yeah oops
<re_irc>
< (@adamgreig:matrix.org)> Cargo can't pick 0.2.7 for that but putting = stops it ever going to 0.2.9, god forbid
<re_irc>
< (@dirbaio:matrix.org)> to avoid higher
<re_irc>
< (@dirbaio:matrix.org)> hopefully there won't be a "0.2.9" though 😰
<re_irc>
< (@dirbaio:matrix.org)> atomic-polyfill v0.1.11 now out
<re_irc>
< (@dirbaio:matrix.org)> Updating crates.io index
<re_irc>
< (@jannic:matrix.org)> However, I wonder if it would be better to just remove the dependency on 0.2.8 instead, as dirbaio did it with nrf-softdevice.
<re_irc>
Pro: Won't break again in case we decide to yank version 0.2.8 :-)
<re_irc>
Contra: The dependency on 0.2.8 prevents the usage of older 0.2.x versions via other dependency chains.
<re_irc>
< (@dirbaio:matrix.org)> I didn't add 0.2.8 to nrf-softdevice because it's not released on crates.io
<re_irc>
< (@dirbaio:matrix.org)> so breaking changes are OK