sbt 2.0 Enters Its Final Stretch as Twelve Release Candidates Bring Scala's Premier Build Tool to the Edge of a Stable Release

Overview

The Scala community’s de facto build tool is approaching a landmark milestone. As of mid-April 2026, sbt 2.0.0-RC12 is live, the twelfth release candidate in a multi-year journey toward a stable major release. In a post titled “Last mile towards sbt 2” published April 14 on the official Scala language blog, lead maintainer Eugene Yokota signaled that the final release is now a matter of “weeks to a few months” pending critical bug discoveries — the clearest timeline the project has offered in years.

What Is sbt and Why This Release Matters

sbt (Scala Build Tool) was first released by Mark Harrah in 2008 and has since grown into the dominant build system across the Scala ecosystem. The Scala 2 and Scala 3 compilers themselves are built with sbt, as are major frameworks including Play and the popular open-source chess server Lichess. In 2023, stewardship of the project transferred to the Scala Center, the EPFL-backed nonprofit that coordinates development of the broader Scala platform.

The jump from sbt 1.x to 2.0 is the first major version bump in the tool’s history and carries breaking changes — but also a set of capabilities the community has long sought.

What Changes in sbt 2.0

The headline architectural shift is that sbt 2.x now uses Scala 3.x for build definitions and plugins, replacing the Scala 2.12 metabuild that has powered every sbt 1.x release. Projects can still compile Scala 2.x or 3.x code — the change affects only what language is used inside build.sbt and plugin files.

Beyond the compiler upgrade, sbt 2.0 introduces:

• Bazel-compatible caching: A local and remote task-result cache allows build artifacts to be shared across machines or CI environments. The cache format is intentionally compatible with Bazel’s remote execution protocol, opening doors to hybrid build pipelines.
• Incremental test execution: The test command now skips tests whose inputs have not changed since the last successful run. Developers who want to force a full suite can invoke testFull.
• Built-in project matrix: Cross-building for multiple Scala or JVM versions no longer requires a separate plugin; the feature is part of sbt 2.x’s core.
• Native sbtn client: A GraalVM native-image client replaces the JVM-based launcher for startup purposes, delivering measurable startup improvements over the JVM-based sbt launcher by eliminating JVM spin-up overhead.
• Non-blocking run task: Through the Build Server Protocol, the run task now executes in a separate JVM via sbtn, keeping the sbt server itself responsive during long-running application launches.
• Maven BOM support: Bill-of-materials dependencies can now be declared directly with .pomOnly(), eliminating a common workaround needed in sbt 1.x projects that integrate with Maven-oriented dependency graphs.

The minimum Java requirement also rises: sbt 2.x requires JDK 17 or later. The IntelliJ Scala Plugin 2026.1 release now displays a warning when a project attempts to use sbt 2.x with an older JDK.

Plugin Ecosystem: 60 Ports and Counting

Historically, Scala developers have been burned by major tooling upgrades that land before the plugin ecosystem catches up. The sbt 2 transition appears to have learned from that experience. According to the April 14 blog post, more than 60 plugins have already been ported to sbt 2.x before the stable release.

Key ecosystem components now supporting sbt 2.x include Scala Native (v0.5.11), sbt-assembly (v2.3.1), and a Play Framework milestone build. Scala.js support is progressing via an open pull request. Metals, the language server used by VS Code and other editors, has updated its sbt 2 integration in tandem.

To ease the migration burden on plugin authors, the Scala Center released the sbt2-compat library in March 2026. The library provides a compatibility shim that allows a single codebase to compile against both sbt 1.x and sbt 2.x, bridging the type-system differences between the two generations — most notably the replacement of java.io.File with context-specific virtual file types like HashedVirtualFileRef and VirtualFile.

Development of sbt2-compat was funded in part by the Sovereign Tech Fund, a German government initiative that provides grants to open-source digital infrastructure projects. The investment reflects the growing recognition of Scala’s role in enterprise and financial-services software.

The Road to RC12

The release candidate cadence has accelerated sharply since late March. RC10 shipped on March 26 with XDG directory standard support, dependency mode controls, and an experimental sbtw launcher. RC11 followed on April 7 with compatibility changes to task output type handling. RC12 arrived on April 13, fixing four specific bugs: test behavior when dependencyMode is set, path expansion for .previous, stack traces suppressed in batch mode, and client-side run status reporting.

With the creation of a dedicated 2.0.x stabilization branch, new features are now being directed toward sbt 2.1, signaling that the maintainers consider the 2.0 feature set complete.

What We Don’t Know

The team has declined to commit to a specific release date, noting that critical bugs discovered during community testing could delay the stable release by weeks or months. The exact scope of remaining edge cases is unknown. It is also unclear how quickly large enterprise codebases — some with hundreds of sbt subprojects and deeply customized plugin stacks — will be able to migrate, given the requirement to rewrite build definitions in Scala 3 and adapt to the changed classpath representation.

Analysis

The sbt 2.0 release, whenever it formally lands, will close a chapter that began in 2023 when Yokota first published the sbt 2.0 ideas post. The long runway — spanning milestones, betas, and now twelve release candidates — reflects both the difficulty of migrating a build tool’s own plugin API and the deliberate, community-consultative approach the Scala Center has taken since assuming stewardship.

For Scala developers, the practical changes are significant: Bazel-compatible caching alone could reshape how large teams share build artifacts across CI pipelines. The Scala 3 metabuild requirement is potentially disruptive for organizations that have maintained Scala 2.12 plugin code for years, but the sbt2-compat bridge and the growing plugin port list suggest the ecosystem is prepared.

The timing also matters for the broader Scala narrative. With Scala 3 now the language’s primary focus and tooling like Metals, IntelliJ, and Coursier increasingly aligned around it, an sbt 2.0 stable release would remove one of the last major infrastructure dependencies on the Scala 2 toolchain.