doctest change is undocumented MSRV bump

[str4d]

#17, which replaced cfg(test) with cfg(doctest), was merged back in May, and released two weeks ago as 0.5.3. However, cfg(doctest) was only stabilised in Rust 1.40.0, which means that this was an undocumented MSRV bump. I ran into problems with this because the tempfile crate has a MSRV of 1.32.0 but depends on remove_dir_all, and no longer builds with older Rust versions.

The ideal solution would be to publish a 0.5.4 that reverts #17 and has the original MSRV, and then re-publish the current version as 0.6.

[XAMPPRocky]

Thank you for your issue! However, I'm only interested in supporting the latest version of the compiler. If you'd like to use a version that is compatible with with 1.32.0 you can continue to use 0.5.2. If you have specific compiler version requirements for your project I would recommend committing your Cargo.lock to avoid this issue.

[str4d]

For further context: I don't directly depend on remove_dir_all; I have a library crate that dev-depends on tempfile, which depends in turn on remove_dir_all. As library crates don't use Cargo.lock files, my workaround was to add a dummy direct dev-dependency on this crate to pin it at =0.5.2.

Choosing to only support the latest compiler version is a perfectly acceptable policy. The problem is that pushing a MSRV-breaking release as a point-release caused all downstream dependencies to start breaking on older Rust versions, as under Rust-flavoured SemVer, point releases are always considered backwards-compatible (and thus cargo always uses the most recent point release). It would be helpful to document your policy in the crate README, so that other libraries with specific MSRVs don't depend on this crate.

[XAMPPRocky]

As library crates don't use Cargo.lock files

This isn't true, while it's typically best practice to not include lockfiles in a library you totally can include your lockfile, and I would recommend you do so if you want to lock your compiler version. Semver unfortunately doesn't cover how to handle tool changes and so it left to the individual to decide their stability policy on upgrading tools. I'm fine with breakage on older compiler versions. This is a crate that I maintain in my spare time, if people want me to support old compiler versions they can pay me to do so.