Skip to content
This repository has been archived by the owner on May 20, 2022. It is now read-only.

consider moving off of nightly #37

Closed
cmyr opened this issue Jun 10, 2021 · 9 comments
Closed

consider moving off of nightly #37

cmyr opened this issue Jun 10, 2021 · 9 comments

Comments

@cmyr
Copy link
Collaborator

cmyr commented Jun 10, 2021

There aren't a lot of great reasons to require nightly rust anymore, and it will be a major barrier to the adoption of this crate elsewhere in the ecosystem. Unless there's a really compelling reason to require nightly, I think it probably makes sense to try and move off of it sooner rather than later, as it will become harder the more nightly features end up being used.

Any thoughts on this? Last I checked nightly was only being used to improve diagnostics in some derive macros, and there are reasonable workarounds there. Are there any other major motivations?

It's worth keeping in mind that we can still conditionally use nightly features, enabling them only when we're on a nightly compiler.

@simoncozens
Copy link
Owner

I’m not sure we need nightly for any of the code in here (we shouldn’t), but I have a feeling we link to crates which need it. I’m happy to get that fixed if possible.

@simoncozens
Copy link
Owner

(cargo test on stable is passing.)

@cmyr
Copy link
Collaborator Author

cmyr commented Jun 10, 2021

yea, playing around more I think this may be a non-issue. I did need to use nightly to run fontcrunch, though?

I'm a bit surprised if we have any deps that are nightly-only, there just aren't that many of those out there anymore, as more and more stuff has come to stable over the years.

@simoncozens
Copy link
Owner

So I just tried this in a VM. fonttools doesn't compile on rustc 1.4.7 because fixed 1.9.0 uses checked_next_power_of_two which is not in stable.

Which makes it a bit of a mystery why the CI build is passing...

@cmyr
Copy link
Collaborator Author

cmyr commented Jun 10, 2021

I believe that's stable as of 1.50, and CI is running 1.52.x.

@simoncozens
Copy link
Owner

And Ubuntu groovy ships 1.47. So they’ll need to futz with rustup anyway. Man, I hate this stuff.

@cmyr
Copy link
Collaborator Author

cmyr commented Jun 10, 2021

I guess it depends who our users are? I don't think it's unreasonable to expect folks to be on the latest stable.

@simoncozens
Copy link
Owner

I've just run cargo test --workspace on stable and (apart from an expected fail) everything works. So I'm closing this.

@alerque
Copy link

alerque commented Jul 1, 2021

I don't think it's unreasonable to expect folks to be on the latest stable.

Confirm.

Moot-ish point now, but in case it comes up again I don't know of any reason not to expect the very latest stable compiler to be available. I'm sure someday that will change, but to date the way the Rust ecosystem moves including distro packaging, the very latest stable tag compiler is an expected thing to have available. Not requiring nightly is a good thing especially for distro packagers, but holding anything back to maintain old compiler compatiblity is not necessary.

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

No branches or pull requests

3 participants