Mark Error as #[non_exhaustive]

[sosthene-nitrokey]

#4 (file) Added a new error variant, which is a breaking change.

[robin-nitrokey]

Would you be fine with reverting the new error variant temporarily and just returning something like SerdeDeCustom or DeserializeBadU32 instead so that we can make a 0.4.1 release? That would make it easier to require specific features by setting a minimum version without having to do a migration to a 0.5.0 release right now.

[sosthene-nitrokey]

I also want to say I'm pretty convinced we're the only ones using cbor-smol. I'd personally be fine with making a breaking change release 0.4.1 and yanking 0.4.0. There are many things that are exposed that I think should not be (the Writer trait and the field of Serializer for example).

Making #13 non-breaking would not be worth it imho.

[robin-nitrokey]

I’m not a fan of (deliberately) yanking for semver reasons. It only has a very limited effect and could be painful if you really need to go back to an old version for some reason. If we want to go that way, I’d prefer to just release 0.4.1 with the technically breaking but practically ineffectual change.

[sosthene-nitrokey]

he technically breaking but practically ineffectual change

Do you mean the error variant or do you include #13 in it?

#13 is a bit bigger of a change, especially since some used features are not available by default (maybe they should be). It also removes the public fields in Serializer but I think it's fine.

[robin-nitrokey]

I did not consider #13. I’d just do a proper 0.5 release for it. We don’t have too many crates depending on cbor-smol so it’s not that much effort to update it.