published indexmap 1.3.1 has broken Cargo.toml about indexmap

[cuviper]

I just used the MSRV (1.18) cargo when publishing 1.3.1, which doesn't rewrite Cargo.toml -- that was introduced in rust-lang/cargo#4030, cargo 0.20.0 (Rust 1.19).

This seems like a pretty serious regression, and is likely to be a substantial impediment to all linux vendors packaging rust.

I think you're overstating the severity. The crates.io package is not broken when used as a normal dependency, and the missing workspace only matters when you try to use it as a primary source. I happen to be a Fedora packager too, and I just patched it out there:
https://src.fedoraproject.org/rpms/rust-indexmap/blob/314395ffa87c370a0ef2bdcc41e7ebddc034beff/f/indexmap-fix-metadata.diff#_18

As a linux vendor, you should already be prepared to make such changes for any crate that was packaged before Cargo.toml rewriting started.

Still, I will make a new release...

[cuviper]

I feel wary of publishing with newer Cargo than MSRV, in case its Cargo.toml rewriting ever does something that's not supported by older Cargo. However, I'm not aware of any such problems yet.

[kentfredric]

I think you're overstating the severity.

Indeed, after filing the bug I found it was easier to patch out than I'd anticipated.

Though thanks for making a new release anyway, where possible, we desire to follow upstream with as few patches as possible :)

[bluss]

I just used the MSRV (1.18) cargo when publishing 1.3.1,

@cuviper Is it important to package like this? Just curious why you've included this in your process.

[kentfredric]

I feel wary of publishing with newer Cargo than MSRV, in case its Cargo.toml rewriting ever does something that's not supported by older Cargo. However, I'm not aware of any such problems yet.

Only problem I'm aware of is the new Cargo.lock layout getting shipped, which doesn't parse with older cargo, but you'll only have that if you ship examples or binaries.