Remove unused fields #1184
Remove unused fields #1184
Conversation
|
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 |
|
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. |
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 |
This breaks serialization compatibility with older versions.
vks
force-pushed
the
remove-unused-fields
branch
from
f5d1db1 to
5f0d3a1
Compare
|
@dhardy I finally updated the changelog, could you please have a look? Thanks! |
This fixes some clippy warnings (due to new lints on nightly).
@dhardy The changes will break serialization compatibility with older versions. Do we have a policy whether that is a breaking or value-breaking change?