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 more shards and apps #5

Open
2 of 8 tasks
straight-shoota opened this issue Jul 21, 2021 · 5 comments
Open
2 of 8 tasks

Add more shards and apps #5

straight-shoota opened this issue Jul 21, 2021 · 5 comments

Comments

@straight-shoota
Copy link
Member

straight-shoota commented Jul 21, 2021

I'd like to add more projects to improve the surface area of tests. We've already discovered two probable regressions in 1.1.0 from the invidious project. So I think that would be a good candidate to add here, for example.

Criteria to include projects here are: Because they are important for the Crystal ecosystem, a large code base (thus using many features) or using specific features of the compiler or standard library. And of course it should be reasonably easy to run test (ideally just checkout and run make test).

Having projects run their own specs on nightly and pre-release builds of Crystal is of course also valuable. I'd encourage every maintainer to do that (it's really easy on GHA with https://github.com/crystal-lang/install-crystal btw.)

Some proposals:

Please add more suggestions.

@beta-ziliani
Copy link
Member

Well, we need to be sure that maintainers will want our PRs if we find an issue in their code. I mean, some breakages might be good. I say this because I don't know how maintained are some of the listed projects.

@beta-ziliani
Copy link
Member

We can always contact the maintainers in doubt. I'm not sure how active is Lilith, for instance, but I understand that this project might shake the language in a way few other projects might do.

@straight-shoota
Copy link
Member Author

Yeah, I don't see the purpose of test-ecosystem to make sure these specific libraries work well with an upcoming release. For me it's primarily about identifying unintended breaking changes.

@beta-ziliani
Copy link
Member

The thing is what we do if we break something for a good reason. We need to be able to tell the developers how to fix their code (and expect the library to progress, otherwise it has to be removed from the list).

@beta-ziliani
Copy link
Member

Let remove lilith from the list, it won't be updated and it doesn't compile now.

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