Release 0.15.3

Fixed

• PR#63 resolved #62 which was a bug introduced in PR#61

Release 0.15.2

Fixed

• PR#61 resolved #60 by refactoring the building of the crate graph to do its own crate and feature resolution to properly handle pruning based on the user's desires.

Release 0.15.1

Added

• PR#59 added Krates::krates_filtered, allowing filtering of crates based upon their edge kinds.

Release 0.15.0

Changed

• PR#58 removed the prefer-index feature, which brought in tame-index, in favor of just letting the user provide a callback that can be used to gather index information, freeing this crate from dependency issues and allowing downstream crates more flexibility.

Release 0.14.1

Changed

• PR#57 bumped tame-index to 0.4.

Release 0.14.0

Changed

• PR#55 and PR#56 replaced crates-index with tame-index
• PR#56 changed Krates::lock_path -> Krates::workspace_root, which can then be joined with Cargo.lock to get the same path, but workspace root is more generally useful.

Release 0.13.1

Fixed

• PR#54 fixed an issue where the crates.io index was unconditionally opened, and synced, if the prefer-index feature was enabled, causing long stalls if using the crates.io sparse index instead.

Release 0.13.0

Changed

• PR#53 updated cfg-expr to 0.14 and crates-index to 0.19.

Fixed

• PR#53 added support for using the HTTP sparse index for crates.io. If the sparse index was enabled and there wasn't a regular git index (for example, if you use dtolnay/rust-toolchain@stable in your CI) this would cause no index to be used to fix crate features if prefer-index was enabled.

Release 0.12.6

Changed

• PR#52 updated cfg-expr to 0.12.
• PR#52 changed Krates::search_matches and Krates::search_by_name to use impl Into<String> for the name to search, so that the lifetime of it is not paired with the graph itself.

Release 0.12.5

Fixed

• PR#51 resolved #50 by no longer treating the feature set in the index as authoritative, but rather just merging in the keys that were not already located in the feature set from the crate itself. This would mean that features that are present in both but with different sub-features from the index will now be lost, but that can be fixed later if it is actually an issue.