Seth Tisue edited this page Jul 22, 2018 · 21 revisions

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.
    • For now, the 2.13 build is a subset of 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.)
  • All of your transitive Scala-based 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.)
    • Note that Java-based dependencies are never a problem; dbuild will just pull those binary JARs from Maven Central. It's only Scala-based dependencies that need to be explicitly included in the community build so they can be rebuilt from source.
  • 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-bin-933bab2. 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.
    • Sometimes it's a lot easier, yet still worthwhile, to get one core subproject, or a handful of them, in.
    • A typical reason to exclude a subproject is that it has additional problematic Scala-based dependencies.
  • It's fine to use any sbt plugin in your build. (We don't build these from source.)

we don't accept:

  • sbt 0.13 plugins, since sbt 0.13 still uses Scala 2.10
  • sbt 1 plugins. perhaps we could, but for now it's out of scope.
    • 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

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

We do include a sampling of other sorts of things, in the interest of having a diverse collection. Projects that have a history of catching Scala regressions are good to get in. So are projects that exercise Scala features that are otherwise underexercised in the build.

If you're wondering if something in particular would fit, it doesn't hurt to ask (on Gitter, or open an issue).

You don't want my project? Really?

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.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.