Decide how to deal with heapless-v0.8

[jamesmunns]

heapless types appear in the public interface, so upgrading it would be a breaking change.

I am not certain, but I've considered doing the following:

• adding heapless-v0_7 and heapless-v0_8 features, using those versions specifically, maybe in some module-d scope, for things like to_vec, to_vec_cobs
• keeping heapless as an alias for heapless-v0_7, but marking it as deprecated.

Open to feedback if people think there is a preferrable solution.

Originally posted by @jamesmunns in #115 (comment)

[jamesmunns]

tagging the postcard-2.0 label so in the future I remember to remove whatever deprecated notice I add for fixing this in 1.0.

[bsodmike]

Hi James,

Latest postcard has a dependency on "heapless 0.7.17" which depends on atomic-polyfill. I'm trying to upgrade my dep tree to move to portable_atomic supports AtomicU64 (and heapless-v0.8 has this as a dep instead).

Do you think you can help with this please?

update: found the master branch resolves, this thanks https://github.com/jamesmunns/postcard/blob/main/Cargo.toml#L32

Cheers

[enbyted]

Hi,

In my view the best approach would be to get rid of other crates in the public API, as you proposed in #128 . However, I assume that releasing 2.0 might take a while, so as a temporary solution doing what you proposed here (having the 2 features flags) sounds reasonable.

In one of my projects I've used heapless 0.8 for quite a while before deciding on using postcard, which means that I either need to do a breaking downgrade now or implement my own heapless (0.8) compatibility for postcard. I guess I could also depend on postcard master, but I'm not really keen on doing so.