Release v0.7.1#382
Conversation
* Fix some clippy warnings * Fix some more clippy warnings Co-authored-by: Rémi Lauzier <remilauzier@protonmail.com>
Fix newtype variant unwrapping inside enum, seq and map
Enable `unwrap_newtypes` extension during serialization
Fix ron-rs#338 value map roundtrip
Added improved `ExpectedStruct` error message
Fix ron-rs#289 enumerate_arrays comments
…enum Fix ron-rs#207 with unit test
Add compact arrays (ron-rs#299) and pretty inline separators
Add struct name mismatch error + better error messages
* Move struct_names from Serializer to PrettyConfig * Update changelog
* Add code coverage CI step * Added codecov badge to README * Exclude examples from codecov collection
Expose `Extensions` during ser+de through `ron::Options`
…-rs#372) Co-authored-by: KirbyER <7432155-KirbyER@users.noreply.gitlab.com>
* Increased coverage for unit tests * Removed unused enum from empty set test
| note = "Serializer::new is deprecated because struct_names was moved to PrettyConfig" | ||
| )] | ||
| pub fn new(writer: W, config: Option<PrettyConfig>, struct_names: bool) -> Result<Self> { | ||
| todo!("figure out how to handle struct_names"); |
There was a problem hiding this comment.
This needs to be resolved before merging.
|
Why were the other three PRs excluded ( |
|
Yes exactly, they are breaking changes. |
|
For v0.8 I think the |
Hmm, it wouldn't right now, would it? I don't think there's a way to get the name of a struct when using |
kvark
left a comment
There was a problem hiding this comment.
Anything to resolve until CI passes and this is published?
|
@kvark |
This is temporary change that should be reverted once the next minor version gets released. It enables semver compatibility with the last release, and is necessary for the 0.7.1 release
|
Okay, I fixed CI and implemented option a. |
Codecov Report
@@ Coverage Diff @@
## v0.7 #382 +/- ##
=======================================
Coverage ? 88.87%
=======================================
Files ? 47
Lines ? 4982
Branches ? 0
=======================================
Hits ? 4428
Misses ? 554
Partials ? 0 Continue to review full report at Codecov.
|
|
@torkleyy Ok, that looks good to me 👍 Perhaps we should document the planned depreciation in the release notes? |
|
LGTM |
|
Thanks for reviewing @MomoLangenstein |
Closes #365
TODO
struct_names@kvark @MomoLangenstein Only four months and four days later and I found some time to do the long awaited 0.7.1 release 😅
I've included all merged PRs since the v0.7.0 release, except:
PrettyConfig#329u128andi128behind optionalinteger128feature #351Changelog
struct_namesoption toPrettyConfig(#329)unwrap_newtypesextension during serialization (#333)unwrap_variant_newtypesextension during serialization (#336)Optionsbuilder to configure the RON serde roundtrip (#343)DeserializeSeedsupport (#360)FromStr-equivalent float EBNF andError::FloatUnderscore(#371)struct_namesissuePull Request #329 moved the
struct_namesfrom theSerializerto thePrettyConfig. This included a breaking change toSerializer::new, removing the third parameter. I see a couple ways to handle this:a) for 0.7.x, include the field in both
SerializerandPrettyConfigand generate struct names if either aretrueAdvantages:
Disadvantages:
PrettyConfigand theSerializer::newargument are controlled by different people and one sets it tofalseb) use the third parameter to override the field in
PrettyConfigAdvantages:
Disadvantages:
PrettyConfigif thestruct_namesproperty gets overwritten -> could besolved by doingpretty_config.struct_names = pretty_config.struct_names || struct_names(but that meansstruct_names = falsewill be ignored)struct_namesno longer an option with compact serializationPrettyConfigwhich ends up emulating non-pretty serialization--> Were we aware that moving the field will no longer allow struct names with non-pretty serialization when merging this change?
c) consider reverting the change
There are a couple things I don't like about this change:
serdestructures or a different RON parser (seems fairly unlikely)But I don't feel very strong about it. Having the field in
PrettyConfigprovides more comfort in most situations IMO, but the edge cases above could be a problem sometimes.