serde feature added

[michalkucharczyk]

Support for serde derivations in no_std.

Part of: paritytech/substrate#12994,
Required for: paritytech/polkadot-sdk#25

[mrcnski]

Looks like there is already a serde_no_std feature we could reuse here: #385

Also, can you add a CI jobs with this feature for bounded-collections?

[michalkucharczyk]

Looks like there is already a serde_no_std feature we could reuse here: paritytech/substrate#385

Can you please elaborate more, how can we reuse it?
Do you mean renaming serde to serde_no_std?

Also, can you add a CI jobs with this feature for bounded-collections?

Good point, will do.

[mrcnski]

Can you please elaborate more, how can we reuse it?
Do you mean renaming serde to serde_no_std?

Sorry, yeah I just meant reusing the same name for the feature.

[michalkucharczyk]

My personal feeling is that serde is just a good name for enabling this feature. It is just about adding serde deps with proper features.

Naming was also discussed in paritytech/substrate#12994:
serde will be used in across substrate.

However I do understand your point to have consistent naming in parity-common. Let me know what do you think?

[mrcnski]

Oh, I see. Yeah, I didn't like serde_no_std, but changing it would be breaking and thought we should be consistent.

Is it possible to have them alias to each other? That way people using serde_no_std can keep using it, but we move to serde in substrate.

[michalkucharczyk]

Nothing better than serde = [ "serde_no_std"] comes to my mind.
I don't know how to deprecate feature.
Found this: rust-lang/cargo#7130, https://stackoverflow.com/questions/56917787/how-to-correctly-deprecate-a-crate-feature.

[mrcnski]

Looks good, not blocking on the feature name. Maybe it's fine without further changes, will let you decide.

[mrcnski]

nit: If we are following semver here, should this technically be a minor version bump? Since we are adding functionality.

[michalkucharczyk]

02f09de

[mrcnski]

Thanks, looks like we weren't very strict about semver in the past, but good to start now. :)

[mrcnski]

Actually, since we're still at 0.y.z we might have been following the common scheme where y is reserved for breaking changes.

The spec recommends always bumping y on new releases when x=0, but probably we shouldn't change the strategy we were already following. Maybe we should revert? 🙈

[michalkucharczyk]

Both are fine for me. But following previous strategy makes sense. I'll revert.