0.3.0 release

[lloydmeta]

• Bump versions
• Add to CHANGELOG.md

[Centril]

Since you're doing 0.3 I would suggest taking the opportunity to migrate to Rust 2018 and also raising the minimum Rust version to something that can take advantage of new improvements... :)

[lloydmeta]

Since you're doing 0.3 I would suggest taking the opportunity to migrate to Rust 2018 and also raising the minimum Rust version to something that can take advantage of new improvements... :)

Ahh, that sounds good, but it's a bit late for that since I just published :D Maybe for 0.3.1 if it isn't massively going to break things 🙂 ?

[Centril]

Presumably you will need to raise the minimum Rust version which will break things? Depends on how you see things... some do not consider the rust version to be a semver matter...

[lloydmeta]

Actually, what’s involved on migrating to 2018?

Maybe my Google foo isn’t strong enough but it doesn’t look like something where I set a minimum Rustc version in the manifest and try to compile and fix errors ?

[ExpHP]

https://doc.rust-lang.org/stable/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html

[ExpHP]

Officially there is no way to declare the minimum supported version of rustc. For many crates, "minimum supported rustc version" (or MSRV) simply refers to the oldest version that they target in CI tests (with the acknowledgement that it may incidentally compile on earlier versions, but those are allowed to break). Frunk does not do any testing on old compilers, so we probably accidentally bump the MSRV quite regularly.

There was a very good discussion somewhere (I can't seem to find it right now) where I think BurntSushi originally had a strong opinion that bumping MSRV is a breaking change, then eventually came around to argue the opposite. To broadly summarize, MSRV only impacts the following:

• Binaries and other top-level crates. These typically have Cargo.lock committed to version control, meaning that everyone who builds them gets exactly the same versions of dependencies (and so they won't implicitly try to use new versions of frunk)
• Package distributors. These people are used to curating sets of compatible package versions, and can just choose whatever version of frunk works for them.

[ExpHP]

Hm. Actually not sure what the best practices are for crates that have optional support for std in 2018 edition.

If this comment reflects the final implementation then I guess the best practice is:

#![cfg_attr(not(feature = "std"), no_std)]

// no extern crate std as you would have in 2015 edition

use core::mem;
use core::fmt::Debug;
#[cfg(feature = "std")] use std::collections::HashMap;

...possibly? I might need to play around with this.