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

Add an optional feature for 1.34.2 backwards compatibility #84

Merged
merged 1 commit into from
Aug 15, 2020

Conversation

HeroicKatora
Copy link
Contributor

@HeroicKatora HeroicKatora commented Jul 1, 2020

The readme states that the crate is compatible with 1.34, however this is no longer true due to relying on extern crate alloc which was stabilized in 1.36. Since alloc is just a subset of std we can restore this compatibility via an optional feature, disabled by default and fully opt-in.

Alternatives

  • Add a features to disable all alloc-dependent items. This isn't really feasible with the current design which relies on Box and Vec internally.
  • Don't do this. Then image might not profit from potential bugfixes until 0.24 :)

@alexcrichton Would this be fine and compatible with std inclusion, by not activating the feature there?

@alexcrichton
Copy link
Contributor

This should work for libstd, yes, but I'd probably recommend to instead just bump the minimum version.

@HeroicKatora
Copy link
Contributor Author

HeroicKatora commented Jul 1, 2020

We had promised not to do that without a major version. Well, it's been almost a year and there are a few potentially breaking changes in the pipeline anyways. I'll consider this another reason to do it.

@oyvindln
Copy link
Collaborator

oyvindln commented Jul 4, 2020

1.34 is what's in debian stable, so I think it may be reasonable to still be compatible with it, if it can be done without causing other issues.

@oyvindln
Copy link
Collaborator

oyvindln commented Aug 5, 2020

Would people be okay with merging this? I see there is some demand for being able to update.

@Alphare
Copy link

Alphare commented Aug 13, 2020

I have commented in #90 the reasons why I'm in favor of this PR being merged.

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 this pull request may close these issues.

4 participants