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.

as long as defmt is not on a stable release any minor release of defmt requires all other crates which use (and sometimes re-export) defmt functionality needs to bump its major release (or minor, if they're on 0.x as well) upon new defmt releases.

with over 750k downloads the defmt crate is already heavily used in the embedded rust ecosystem (see also the dependent crates) and having a stable release would be beneficial for all of them.

see also the long-standing embedded wg issue on pushing central crates to v1.0: rust-embedded/wg#383

[BriocheBerlin]

Thanks a lot for your comment! Of course you are absolutely right, however we can't come up with such a road map right now. We're aiming at giving an update early next year; sorry for the delay.

[rursprung]

is it by any chance "early next year"? 🙂

the dependencies of my published libs to defmt are optional, but the feature for it is currently called defmt. i've seen others which have now switched their feature to defmt-03 so that they can add a future defmt-04, defmt-1, etc. feature when needed without having to remove the existing one, thus avoiding breaking changes. but on the other hand it'd be nice to not have to carry around 0.x dependencies if possible (or at least have a roadmap by when that can be removed).

[rursprung]

small bump here - is there any news on this? it'd be great if you could publish a roadmap to v1.0 so that the wider ecosystem knows what'll come and has a rough idea by when it'll come

[jonathanpallant]

I expect we will make an announcement regarding our roadmap shortly. Thank you for your patience.

[jamesmunns]

I just wanted to follow up (especially with @BriocheBerlin and @Urhengulas as we've chatted before!), I'm making quite a bit of progress with postcard-rpc's wire header format, and now have header compression that makes it possible to only add a 3-byte header over postcard-formatted data, and allows for arbitrary message content within.

Right now I'm focusing on "schemas in the firmware" (sort of like the defmt decoder table, but in flash instead of in the elf), but also have some sketches for how I'd do it if I wanted the schemas to live elsewhere (like in the elf, or a separately generated description file).

The header format is described here, and some detail on how I do "perfect hashing" for getting unique message ids/"Keys" here.

Just noting that I'm happy to share notes if you are looking for solutions in this regard, and as before, totally cool if these changes are too out there to be useful for defmt 1.0 :)