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

Support MSRV concept #242

Closed
YeungOnion opened this issue Jun 8, 2024 · 4 comments · Fixed by #268
Closed

Support MSRV concept #242

YeungOnion opened this issue Jun 8, 2024 · 4 comments · Fixed by #268

Comments

@YeungOnion
Copy link
Contributor

We tried this out for the #235, but ran into some trouble when dev-dependencies were not able to satisfy the version that the lib can. Since it's not tested while on crates.io, perhaps this is a non-issue, but it does mean that the CI will fail because of dependencies that we currently use for benchmarking. It would be nice to ensure that the tests will run on our MSRV. Any other input welcome here regarding what one would expect of the MSRV information and what might be unexpected or where you would expect to look for information if something isn't going your way when using this dependency.

@FreezyLemon
Copy link
Contributor

FreezyLemon commented Aug 7, 2024

Is there a target for the level of backwards compatibility? The concept of a MSRV has been discussed before, but the actual minimum version that should be supported has not been, I don't think.

I'll give you some examples to illustrate what I mean (these are "targets" I've seen in other projects before):

  • Support all rustc versions that are shipped by the Ubuntu LTS repositories (or another distro)
  • Support the current rustc stable and X versions before it
  • Support the last X months of rustc stable releases
  • Don't target anything, just use MSRV to inform users what is supported, change MSRV whenever needed or wanted

I should add that there does not have to be a formal MSRV policy, a lot of projects just provide backwards compatibility on a best-effort basis.

All of these have pros and cons. I personally would tend towards not going too far with backwards compatibility as it causes a significant maintenance burden the further you go (and not being able to use new language features is no fun).

@YeungOnion
Copy link
Contributor Author

At the moment, I'm leaning toward the least stringent which is the last option,

Don't target anything, just use MSRV to inform users what is supported, change MSRV whenever needed or wanted

On the basis that there's not a large usage volume of this crate, and I think knowing more about the breadth of use for this library would be helpful.

@FreezyLemon
Copy link
Contributor

I honestly agree, it's the simplest option and unless there's an explicit request for more backwards compatibility, it probably doesn't make sense to overthink it.

@YeungOnion
Copy link
Contributor Author

Yeah, seems like a good approach for now. Glad for your putting a light on it so it's intentional.

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

Successfully merging a pull request may close this issue.

2 participants