I don't think we do have a policy there. It could be considered API-breaking since older serialised values will not deserialise.

I also think it should be considered a breaking change (this is one of the reasons why I am generally conservative regarding implementation of the serde traits).

So we have to treat fields of serializable struct as public? Personally, I would rather treat it like value stability. Serializing and storing the seed are similar use cases.

What is the difference between "value-breaking" and "API-breaking" in this case? Both imply it cannot be merged into "0.8.x". In regards to post-1.0 minor releases, they are one of those weird things that the packaging system effectively treats as a breaking change but semver spec says should not be. In that case I'd be inclined to say we should decide on a case-by-case basis based on how likely the change is to be noticed — but we can talk about this later.

What is the difference between "value-breaking" and "API-breaking" in this case? Both imply it cannot be merged into "0.8.x".

That's fair, but this applies to the distinction between value-breaking and API-breaking in general, no? Before 1.0, our distinction between value-breaking and API-breaking does not make a difference for versioning.

Well... I see no other reason you would care about the distinction?

If we decide on a policy for serialization stability now, it will affect future releases (including post-1.0), where it does make a difference.

This still needs an update to the changelog.

Agreed (your PR).

This targets rand_distr (other than a Clippy fix); I think we can land breaking changes there too.

@dhardy I finally updated the changelog, could you please have a look? Thanks!