chore: Update dependencies (Cargo.toml)

[polarathene]

Consistently omit patch version.

Package notes:

• lazy_static to 1.4 (note that this crate is deprecated officially, in favor of once_cell).
• warp:
  • Previously fixed to a specific version = in Nov 2021 due to concern with MSRV
  • Bumped in Sep 2022 despite no response from issue raised to the warp maintainer.
  • Mar 2022 comment states warp MSRV was 1.51 at the time, which is also when "const generics" feature was introduced (March 2021).
• Removed duplicates of serde and lazy_static were repeated in dev-dependencies for some reason in Dec 2021. That also added notify with the ^ qualifier, but this is the implicit default and stripped away from dependencies in this project some time ago.

---

Outdated (not likely helpful)

UPDATE: This information may not be that useful to anyone else, hence the collapsed section. It's mostly been superseded by what I learned when preparing #495

Other MSRV history since the March 2022 warp reference:

• In March 2022 config-rs documented a version bump of MSRV from 1.49 to 1.56 (Nov 2021).
• In March 2023 config-rs bumped MSRV from 1.60 to 1.64 (Sep 2022) due to dev-dependency temp-env.
• In September 2023 config-rs bumped MSRV again to 1.66 (Dec 2022), with no documented reason for the requirement this time.

You may want to update Cargo.toml to communicate MSRV better via rust-version.

• EDIT: A contributor expressed reluctance to set an explicit rust-version. At the very least, the real MSRV required for published crate should be identified, perhaps via cargo-msrv?

---

AFAIK, the patch versions have been set often without bumping, and without any actual requirement to make that the minimum patch version. So they are not actually serving much purpose.

Initially I misunderstood these to implicitly be = (fixed), hence the original motivation of the PR. As that's not the case, this does raise lazy_static to 1.4 as a minimum, which could be reverted. lazy_static last released 1.4 in Aug 2019, so I don't consider that a concern.

EDIT:

• A recent example with one of the projects dependencies releasing with a major.minor semver dependency of their own, and that dependency later pushing out a point release with a feature only stabilized since Rust 1.71 (July 2023), which leaked through to config-rs CI catching the failure (but could just as easily slipped through like for rust-ini if the timing was a little later with the ordered-multimap crate patch release? 🤷‍♂️ )
• There was another recent one with ahash too (upstream issue), but since resolved.

---

Additionally, the version field is set to 0.13.1, while crates reports 0.13.3? (EDIT: 0.13.x is maintained via a separate branch, related PR raised)

Another possible update is the edition to 2021 🤷‍♂️

[polarathene]

@matthiasbeyer I've been granted maintainer rights to config-rs by @mehcode

• I am more of a drive-by contributor and don't expect to continue being a maintainer in the long-term, just leaving the project in a slightly better state than when I arrived with the current contributions 😎
• None of my PRs are pressing, I'll leave time for you to recover and provide review/approval (or at least express interest in doing such), otherwise later next month I'll assume I'm trusted to merge as I see fit.
• There are some other PRs that fix bugs that I'd merge too so that they don't go stale, but I am not that experienced with config-rs or Rust to confidently review, so I may miss some concerns you'd otherwise spot.

After that burst of activity, I don't think I can continue to assist maintaining the project much. I've got too many commitments to handle already 😅

[matthiasbeyer]

Yes, I requested you to be added! I saw that you're doing a lot of stuff and I didn't want to slow you down by slow reviews and merges! So go ahead and do what you think is necessary!

[matthiasbeyer]

Ah, to amend on the above (and because it also came up elsewhere): I care a lot about clean commit history (as you probably already noted). That means, please don't do squash merges, not even for single-commit-PRs. And do not remove the gitlint CI job. I know it can be annoying to care about all the details to make it green, but IMHO it is worth it.

Besides that, feel free to take this project to new highs! Especially as I have only been a passive maintainer (except for the config-rs-ng stuff). 😆

[polarathene]

Another possible update is the edition to 2021 🤷‍♂️

For reference, in the recent PR I reviewed (PEM custom file format example), I added a suggestion to improve it which worked fine locally using the 2021 addition with an array iteration, but on 2018 required prepending vec! (the contributor had a more verbose typed workaround prior to that though).

[matthiasbeyer]

Rebased and will merge if CI is green.