Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Breaking Changes #58

Open
6 tasks
CraftSpider opened this issue Feb 12, 2024 · 1 comment
Open
6 tasks

Breaking Changes #58

CraftSpider opened this issue Feb 12, 2024 · 1 comment

Comments

@CraftSpider
Copy link

There was discussion in #56/#57 about breaking changes, upping MSRV, etc. I wanted to collect thoughts/ideas/etc somewhere, and a list of things desired for a next update.
@waych / @pkgw feel free to comment on anything to add/remove from this list.

  • Bump MSRV
    • Hard to find really good numbers, but https://lib.rs/stats#rustc implies that of the top 4000 crates, only a handful compile on rustc older than 1.31, so if we want to be 'maximally compatible', that might be a good number
    • Alternatively, 1.40 gets us #[non_exhaustive], which would help reduce breakage by allowing public structs and enums that can be later extended.
    • 1.56 is the next major bump in how many crates support it, so is probably the most logical choice after the above
  • Delete deprecated things
  • Fix NotMSVC error codes / spaghetti target code
  • Improve type extensibility, make some stuff private
  • General cleanup - General code cleanups #57 is a start on this
  • Add support for determining library versions - Add code to expose the selected version of a requested package #56, on the list because it requires breaking Library
@pkgw
Copy link
Collaborator

pkgw commented Feb 12, 2024

I'd recommend aiming for at least 1.40 for non_exhaustive — it would be nice for a breaking release to be "lightly breaking", where hopefully a lot of consumers will be able to update without changing any code. To be more future-proof with Library without non_exhaustive would require a more invasive change, AFAICT.

For the spaghetti target code: the code in tectonic_cfg_support should hopefully be a nice reference for properly handling the CARGO_CFG_TARGET_* variables; my impression has been that a failure to properly respect those has been a source of a lot of the spaghetti-ness there.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants