Bump version to 0.6.0

[torkleyy]

No description provided.

[kvark]

Is this just for base64? I'd rather not have a dedicated release then, for now, until we have more breaking changes accumulated.

[kvark]

@CAD97 if you are interested in this, we basically need a short overview of all changes that went in since the last release. Admittedly, we are missing a tag/branch for latest 0.5 release, this is no good and need to be fixed as well. Once this little investigation is done, we can both create a branch for 0.5, and add a CHANGELOG listing at least stuff changed between 0.5 and 0.6, following up with the sections for earlier revisions later.

Also, all the pending issues that would require API changes need to be triaged for the prospect of including into this breaking release.

If you (or anyone) are willing to help with this, it would be great!

[CAD97]

Checking the source downloaded from crates-io, the published commit seems to be 6e9f7dd for 0.5.1. (Methodology: 0.5.1 was published on Apr 5. Above commit is a bors commit on Apr 5. The code landed by that merge is present. The code from the following commit, d25ea20, appears to not be present.)

That means all of the following PRs have landed but not yet been published:

• Be smarter about integer deserialization #157 (Fixed deserialize_any treats integers as f64 #100, Deserializing large serialized Value::Number fails #155)
• Add VS code language tooling #160
• chore: Update serde_bytes to 0.11 #164
• Implement inf, -inf and NaN handling #163 (Fixed f64::INFINITY causes panic #159)
• Parse integers ourselves, fix MIN parsing #161 (Fixed Deserializing std::i*::MIN integer fails #158)
• #123: add tests for different enum representations #166 (Addressed Externally, internally, adjacently and un-tagged enums #123)
• Ensure "Untagged tuple-like enum variants not deserializing correctly……" is fixed #170 (Fixed Untagged tuple-like enum variants not deserializing correctly #117)
• Note that raw strings are not context-free #171 (Fixed raw strings in rust are context-sensitive #167)
• Make PrettyConfig future-proof! #173
• Use indexmap to preserve order (optional) #172 (Fixed Feature request: preserve order in value #129)
• Fix syntax highlighting for example #187
• Allow pretty ser to work with implicit-some extension #182
• Fix typo in documentation comment. #188
• Remove unneeded Neg requirement for signed_integer #193
• Update base64 requirement from 0.10 to 0.11 #195
• Testing for RON files #197
• Update base64 requirement from 0.11 to 0.12 #204
• Remove deprecated uses of Error::description. #208
• Support i128 and u128 #219

If we're talking about fitting in more breaking changes, it would be great if ron could conform to the serde data format conventions for API surface, which is basically just

mod de;
mod error;
mod ser;

pub use de::{from_str, Deserializer};
pub use error::{Error, Result};
pub use ser::{to_string, Serializer};

I'll look into what's required for that.

[kvark]

Thank you! At the minimum, we still need to triage all the open issues to see, which of them require breaking changes and can be done.

[CAD97]

Triage

• [RFC] Separate number types #47: breaking
• Register in Linguist database #85: external
• Date and time #91: breaking, but honestly I don't think we want a date primitive
• Struct flattening not working #115: additive
• Current issues with Value #122: breaking
• Externally, internally, adjacently and un-tagged enums #123: tests
• Conversion between Value and any T: Serialize/Deserialize #140: additive (but with a rename suggested)
• Implement ron! macro #143: additive
• Control integer representations #144: additive
• Edge case where RON fails but all other serde format types succeed #152: external? fixed?
• Depth limit seems to be off by one #174: breaking (bugfix)
• Current Serializer is hard to maintain #175: internal?
• Add code coverage badge #176: meta
• [RFC] Add a tokenizer as intermediate step #178: probably internal
• Help wanted: error in my modification of parser #180: help
• Investigate compile sizes #185: meta, external(?)
• to_string(from_str::<Value>("ron")) should be lossless #189: probably breaking
• Static Check tool #191: external
• Testing for valid ron files #192: help
• How to specify whether to emit optional struct name during serialization? #200: additive
• Clarify multiline comments support #201: help
• Add function to serialize to a Writer #202: additive
• Some errors are missing line number information. #203: additive (probably)
• Adjacently tagged enums fail to deserialize #207: additive (probably)
• How do I round trip ron files preserving formatting and comments? #216: external, additive
• Nested untagged and externally tagged enums fail to deserialize #217: additive (maybe impossible?)

I'll be honest: poking around in ron's code, I'm starting to feel that we could (should?) just start over, especially because of #175. Specifically, migrate ron to be just about parsing the data format, and create serde_ron to handle the serde part (the way that serde_yaml uses yaml-rust).

I've already implemented a "better" parser once, and would be happy to do the implementation work to get said split design up to parity with this version.

TL;DR: I think go ahead and publish 0.6 as-is, and start work on 0.7 that's pretty much a fresh start. And apparently I'm volunteering to do the initial impl work for the 0.7 rewrite.

[kvark]

Thank you for classifying the issues! Looks like we can fix #174 and indeed go ahead with 0.6.
@torkleyy any feelings about this?

And apparently I'm volunteering to do the initial impl work for the 0.7 rewrite.

That's a big task, but it looks like you are capable of accomplishing it. This is much appreciated!

[kvark]

Closing in favour of #234