-
Notifications
You must be signed in to change notification settings - Fork 60
Eligibility
You're of course welcome to add any project to the community build and try it in the build yourself locally.
But should you submit a pull request to be added to the official build?
- Your project must target Scala 2.13.
- We are no longer accepting new projects for the 2.12 build.
- Your project must have an sbt build. (It doesn't need to be the main build that you use yourself, but it must exist and work.)
- Your project must be an open-source project hosted in a public Git repository.
- At the moment, everything in the community build is hosted on GitHub. We assume other hosting services would work, though.
- If you use a different version control system such as Subversion or Mercurial, consider establishing a Git mirror.
- Your project must target JVM Scala. (It's fine if other back ends such as Scala.js and Scala Native are supported, but we will disable those portions of your build.)
- Your project must have a stable development branch or tag we can reference.
- If you have a branch where you never, ever commit changes that break CI, great, we'll track that. Else, we'll just point to a particular tag or SHA. (Which can then be updated from time to time.)
- Your tests should not be prone to spurious failures.
- Note that it's really best if we can run your tests. But if we have to disable them and can only check to make sure your code compiles, well, it's better than nothing.
- Your build must not be fazed by Scala version numbers such as
2.12.1-bin-933bab2or2.12.1-bin-933bab2-SNAPSHOT.- Instead of taking apart
scalaVersion.valueyourself, we suggest using sbt'sCrossVersion.partialVersion.
- Instead of taking apart
some non-requirements:
- It's fine if you support multiple Scala versions via sbt's cross-building feature, or by branching. dbuild can cope either way.
- It's fine to only have certain subprojects in your build included.
- Sometimes it's easiest, and still worthwhile, to get one core subproject, or a handful of them, in.
Our top interest is in established open-source libraries on which a substantial number of other projects (open or closed source) depend, directly or transitively.
We also want a diverse collection of projects, to exercise Scala features and coding styles that might otherwise be under-exercised in the build. Projects that have a history of catching Scala regressions are especially good to get in.
The community build's main purpose is regression testing the Scala compiler, as a supplement to the main regression test suite that is maintained in the scala/scala repo. Inclusion remains subject to Lightbend's sole discretion. We occasionally remove projects to maintain a good cost/benefit ratio of maintaining the build from an engineering perspective, as well as the operational cost.
If you're wondering if something in particular would fit, it doesn't hurt to ask; just open a discussion or pull request on GitHub.
You probably have two motives:
- To help us test new versions of Scala
- To find out early if a change to Scala breaks your project
Re goal #1: thank you! Your interest and concern is very much appreciated.
But for both goals, you don't really need dbuild. We publish nightly builds Scala 2.12 and 2.13, so you can just do your testing with those.
It would be marvelous, and we would be grateful, if you used your own preferred CI setup (for example, GitHub Actions) to routinely build your own project against the latest nightly builds. See https://github.com/scala/scala-dev/issues/648 for advice on this. Please let us know (for example, by opening a bug report, or by talking to us on Discourse, Discord, etc) about any suspected regressions that you find.
If you really want to help Scala by helping QA new Scala versions, Scala 3 is now the area of greatest need, not Scala 2.
Perhaps your project could be added to the Scala 3 community build.
Please also consider adding Scala 3 nightlies to your own cross-build in your own CI.