roadmap to v1.0.0?

[rursprung]

do you have a roadmap to releasing a v1.0.0? it would be cool if you could create the tickets for what you think is missing for v1.0.0 and assign them to a v1.0.0 milestone.

rationale: theoretically, one should only build on released software, so using 0.x pre-releases for production software isn't looked on too well. in the rust eco-system there are sadly a lot of crates which stay on 0.x for years but are heavily used. having a roadmap helps in understanding why a crate is not yet released as 1.x (or higher) and allows analysing the trade-offs (is it acceptable to use the crate in production even though these features are missing?).

furthermore, this would help with contributors: they know where work still needs to be done and they can offer their help focused on these topics.

specifically i have a crate which exposes an API using heapless::Vec, so i do not feel confident releasing a v1.0 of my crate as long as my API might suffer breaking changes from heapless (every time you release a new 0.x release i'd have to release a matching major release).

with over 8 million downloads the heapless crate is heavily used in the rust ecosystem (see also the dependent crates) and having a stable release would be beneficial for all of them.

[newAM]

The only thing I worry about is the hash32 dependency is still a zero-ver, I need to look into that more and see if there's something we can do there.

[rursprung]

The only thing I worry about is the hash32 dependency is still a zero-ver, I need to look into that more and see if there's something we can do there.

if it is not exposed in your API (i admittedly didn't check) it should be safe for you to create a stable release as you can still do major version updates of dependencies without breaking your API (and thus requiring a major release).
i've raised an issue with hash32 to see what's blocking them from releasing v1.0: rust-embedded-community/hash32#17

[jordens]

I'm all in favor of pushing for 1.0. But since in 0.7->0.8 we just now changed API in several places, it may be prudent to let the dust settle on that.

[newAM]

I'm all in favor of pushing for 1.0. But since in 0.7->0.8 we just now changed API in several places, it may be prudent to let the dust settle on that.

I agree, I would only feel comfortable with a hypothetical 1.0 after the 0.8.x series has more daily downloads than the older versions.

At the moment the older versions of heapless still get ~15x more downloads, and I expect there are still more issues to be found.

[jamesmunns]

edit: I feel less strongly about this now, see below: #410 (comment).

Just dropping in to voice a +1 to a 1.0 release. I made heapless a part of postcard's public API, and I'll need to do some unfortunate hacks to support 0.7, 0.8, and hopefully soon 1.0. I'd really prefer if 1.0 was the last stop! Right now postcard is one of the largest dependents on heapless, and is still stuck on 0.7 as I'm still hoping to think of a more pleasant way to handle this before an eventual postcard 2.0.

Cross linking: jamesmunns/postcard#121

[jordens]

Question out of curiosity, @jamesmunns: why did you choose heapless::Vec over tinyvec::ArrayVec? The latter is v1. Does the maybeuninit optimization make a difference? Is it the community momentum towards heapless?

[jamesmunns]

@jordens the answer is generally:

• Tinyvec didn't exist yet when I initially wrote postcard roughly 5 years ago, and heapless did.
• I still wasn't aware of it (or at least - hadn't used it before) 1.5 years ago when I made the 1.0 release, and heapless was/is very widely used in embedded rust then and now, and at the time I had no reason to change.

I'm open to switching, if you'd like to discuss that, particularly if you feel like tinyvec would be a better long term fit, but that's still a breaking change since heapless types are in my public API.

[jordens]

Ack. I very much appreciate and understand that perspective. This might be a typical situation for many other users of heapless::Vec.
I don't have enough experience or data to say what's best. That's why I'm wondering.
I remember doing some hours of experimentation to figure out how reliable and useful MaybeUninit optimizations are in our use cases (see also these comments which indicate that there are a many cases where the compiler can't take advantage and also didn't for a long time, e.g. #305) and back then it seemed unclear. No idea what the overall effect is.

[jamesmunns]

Just want to chime in, I'm still a proponent of heapless making a 1.0 release, but want to note that even if that happens, some day there will be a heapless 2.0, which means that I still shouldn't have made it a(n unconditional) part of postcard's API.

I'll likely be doing a postcard 2.0 release anyway, to make it easier to support breaking changes of deps: jamesmunns/postcard#128