Eligibility

Is my project eligible?

You're of course welcome to add any project to the community build and run the build yourself locally. Doing so is easy (though the first run will take hours).

But should you submit a pull request to be added to the official build?

Technical requirements

• Your project must target Scala 2.12. (We are no longer accepting new projects for the 2.11 community 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 not be Scala.js-only; it must support Scala on the JVM. (It's fine if both are supported, but we must disable the Scala.js portion of your build, since at present we are only targeting JVM Scala.)
• All of your transitive Scala dependencies must be in the community build as well.
  • Furthermore, your project must be source-compatible with the versions of those dependencies that are in the community build. (Everything in the community build is built from source, so it doesn't matter what exact version your libraryDependencies lists; dbuild will override it.)
• 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 project must be able to correctly handle Scala version numbers such as 2.12.1-933bab2-nightly.
  • Instead of taking apart scalaVersion.value yourself, use sbt's CrossVersion.partialVersion.
  • Don't assume that scalaBinaryVersion is always a short string such as 2.12. It might be e.g. 2.12.0-RC1 or 2.12.1-933bab2-nightly. Again, use CrossVersion.partialVersion.

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 if you only want certain subprojects in your build included.
• It's fine to use any sbt plugin in your build. (We don't build these from source.)

we don't accept:

• sbt plugins, since sbt still uses Scala 2.10
  • if only part of your project is an sbt plugin, make sure it's in a subproject so we can explicitly exclude it

Other requirements

At present, everything in the community build is an established open-source library on which a substantial number of other projects depend (directly or transitively).

In the future, we might broaden the scope, but for now, we cannot accept other kinds of projects.

Aww, really?

Sorry, yeah.

You probably have two motives:

1. To help us test new versions of Scala
2. 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 of Scala 2.11 and 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, Travis-CI) to routinely build your own project against the latest nightly builds. Please let us know (for example, by opening a bug report, or by talking to us on Gitter, the mailing lists, etc) about any suspected regressions that you find.