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

Track which crates build on stable #115

Open
adamgreig opened this issue Nov 13, 2018 · 7 comments
Open

Track which crates build on stable #115

adamgreig opened this issue Nov 13, 2018 · 7 comments

Comments

@adamgreig
Copy link
Member

Now that Rust 2018 is almost upon us, embedded Rust crates can hope to start working on stable Rust. We should update the awesome-embedded-rust list to track which crates do or do not work on stable.

I imagine this being either a badge (but see #32) or a note or a new section.

Hopefully many crate authors will be update their listings themselves, but if not it is also hopefully not too much work to test arbitrary crates to find out. I think ideally our standard for inclusion should be "the project's public CI indicates it builds on stable".

@therealprof
Copy link
Contributor

I think ideally our standard for inclusion should be "the project's public CI indicates it builds on stable".

I don't think we can (or want to) enforce either (CI and builds on stable).

@adamgreig
Copy link
Member Author

I seem to remember a long while ago seeing a guideline that projects should have working CI for inclusion but I certainly can't find it now so I'm probably misremembering. Working CI on stable is a very very clearly indicator that it builds on stable though. What else do you think would be OK? Someone just adding a PR to say it does, or a member of the resources team manually building the crate?

@therealprof
Copy link
Contributor

therealprof commented Nov 13, 2018

@adamgreig https://github.com/rust-embedded/awesome-embedded-rust/blob/master/CONTRIBUTING.md ?

I'm not actually certain we want the stable badge. I'd probably even go the other way round and tag those crates which are known to only work on unstable; there will always be a good reason why something is not able to work stable and still is awesome.

@BenBergman
Copy link

It probably makes the most sense to tag things in such a way that the tags are least likely to become stale. If I were to see a list where some items have a special label, I would expect those labels to be accurate.

Is it more likely a crate will be labelled at stable and then need to move back to unstable or that a crate will require unstable and then become stable compatible? Whichever is least likely to change should get a badge (if a badge is required at all).

@adamgreig
Copy link
Member Author

A key idea of "builds on stable" is that it really should remain true thereafter, which is why it's such a nice milestone that embedded apps can finally build on stable. Conversely a crate that's currently unstable hopefully will start building on stable soon if it is still maintained! So I definitely think labelling the "builds on stable" crates is the way to go, not the "unstable only" ones.

Sure, some things might not start working on stable especially soon, but it's not like we're saying we won't list them - they just won't get the "builds on stable" tag, which might hopefully encourage crate authors to get their things working on stable and be helpful for users finding crates they can use without nightly.

@therealprof
Copy link
Contributor

I'm still a bit clueless about how we're going to determine whether a crate builds on stable or not or do we trust the submitter?

@adamgreig
Copy link
Member Author

I think if the submitter files a PR to report their crate builds on stable that's fine; we could encourage they have CI showing it builds on stable (really no reason for any project to not at least have Travis build it on stable Rust); and resource team members could also attempt to build-on-stable other crates if we want to mark them.

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

3 participants