Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

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

No branches or pull requests

2 participants