sbt: the interactive build tool, now split across repositories for 2.x

A build tool, described in two sentences

The README's description is two lines, sbt is a build tool for Scala, Java, and more, and for general documentation see scala-sbt.org. The word interactive in the repository's subtitle is the distinguishing feature, sbt runs as a persistent session where compile, test and run commands respond in sequence without relaunching a JVM per invocation, incremental compilation keeping the cycle short. The audience is every Scala developer, since sbt is the ecosystem's default build tool, and the more extends to Java projects and the polyglot builds the community maintains. The Scala index badge and the Discord link on the README's first line place it in the ecosystem's infrastructure rather than beside it.

The 2.x split across repositories

The 2.x section explains an architectural fact users of 1.x never saw, the source code of sbt is split across several GitHub repositories. sbt/io hosts the sbt.io module handling file system operations, sbt/zinc hosts Zinc, an incremental compiler for Scala, and the sbt/sbt repository itself hosts the modules implementing the build tool. The split matters for contributors and for anyone reading sbt's source, the incremental compiler that makes sbt fast is a separate project with its own release cycle, reusable beyond sbt, and the io layer similarly stands alone. A historical footnote keeps the lineage searchable, sbt/sbt-zero-seven hosts sbt 0.7.7 and earlier versions, the pre-1.0 era preserved in its own repository.

The machinery in the tree

The repository's directory list reads as a build system's anatomy. client and the server machinery implement the network protocol between the sbt command and a running build, with server.md documenting it, launch and launcher-package produce the launcher that downloads and boots a configured sbt version, sbt-remote-cache carries the remote caching work, lm-core and lm-coursier implement library management through the Coursier resolver, and main, main-settings, main-command and main-actions hold the settings engine and command surface. Util-cache, protocol, tasks and testing modules fill out the infrastructure, and the sbt and sbt.sh scripts at the root are the entry points, the whole assembled by a build.sbt file, the tool building itself.

Release trains and the develop branch

The default branch is develop, and the release history shows the two-track pattern, v2.0.9 landing as stable on 2026-09-14 while v2.1.0-M2 and v2.1.0-M3 shipped as milestones on 2026-09-21 and 2026-09-28, the M suffix marking the milestone releases ahead of the 2.1.0 final. The repository was pushed 2026-09-27, so the branch and the tags move in step. For users the practical reading is that the 2.x generation is current and actively developed, milestone builds exist for early adopters, and the Setup documentation describes the latest binary release, the version most projects should install rather than the milestones.

Contribution gates, and where questions go

The contribution rules are explicit about process, read CONTRIBUTING.md carefully before opening a GitHub issue or a pull request, with a separate contributing-docs directory for documentation contributors. For those looking for work, issues labeled good first issue or help wanted are named as starting points, both linked as filtered searches. The question routing splits by depth, the sbt channel on Scala Discord for questions, but it would be good to gather questions on Stack Overflow, where answers accumulate and search, and the sbt-dev Google group remains linked for development discussion. The FAQ page explains how to get help and more, completing a support surface that separates ephemeral chat from durable answers.

A codebase with agent-era furniture

The repository root carries the current era's files alongside the traditional ones, AGENTS.md and CLAUDE.md configuring coding agents, an LLM_POLICY.md governing AI contribution, scala-steward automation config, scalafmt and scalafix definitions enforcing Scala style, a devcontainer, jvmopts and java-version pinning the build JVM, and a community-build directory, the cross-project compilation check that validates sbt against the Scala ecosystem's real codebases. PROFILING.md documents performance work, SUPPORT.md and NOTICE complete the governance set, and git blame ignore revisions keep history readable through large formatting commits. The furniture shows a project managing its own complexity with the same tools it asks its users to adopt.

Editorial conclusion

Use sbt when building Scala or mixed Scala and Java projects, where its incremental compilation through Zinc, interactive shell and settings model are the ecosystem defaults, and get started through the Setup documentation on scala-sbt.org rather than building the repository, which exists for contributors. Verify the version line you adopt, the 2.x series is the current generation with 2.0.9 stable and 2.1.0 milestones, read CONTRIBUTING.md before opening issues, and take questions to Stack Overflow or the sbt channel on Scala Discord, the two channels the project names for different purposes.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sbt/sbt on GitHub