-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release v0.7.1 #382
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
src/ser/mod.rs
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
#329u128
andi128
behind optionalinteger128
feature #351Changelog
struct_names
option toPrettyConfig
(#329)unwrap_newtypes
extension during serialization (#333)unwrap_variant_newtypes
extension during serialization (#336)Options
builder to configure the RON serde roundtrip (#343)DeserializeSeed
support (#360)FromStr
-equivalent float EBNF andError::FloatUnderscore
(#371)struct_names
issuePull Request #329 moved the
struct_names
from theSerializer
to 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
Serializer
andPrettyConfig
and generate struct names if either aretrue
Advantages:
Disadvantages:
PrettyConfig
and theSerializer::new
argument are controlled by different people and one sets it tofalse
b) use the third parameter to override the field in
PrettyConfig
Advantages:
Disadvantages:
PrettyConfig
if thestruct_names
property gets overwritten -> could besolved by doingpretty_config.struct_names = pretty_config.struct_names || struct_names
(but that meansstruct_names = false
will be ignored)struct_names
no longer an option with compact serializationPrettyConfig
which 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:
serde
structures or a different RON parser (seems fairly unlikely)But I don't feel very strong about it. Having the field in
PrettyConfig
provides more comfort in most situations IMO, but the edge cases above could be a problem sometimes.