Scala 2.12 shipped a release after 2.13.x did, and that is the maintenance story

2.12.x shipped a release after 2.13.x did

The three most recent releases are v2.12.21 on 2025-12-08, v2.13.18 on 2025-11-17 and v2.13.17 on 2025-09-30. The older line therefore produced the newest artifact, three weeks after the newer line did, while the default branch 2.13.x kept receiving pushes, the most recent on 2026-11-02. Anyone selecting a version by recency will draw the wrong conclusion here, because the newest tag is on the branch the project describes as under minimal maintenance. The reason both lines keep shipping is the merge forward policy: changes are periodically merged from 2.12.x to 2.13.x, so a fix made on the old line can still surface in the new one. The practical consequence for a team is that pinning by date and pinning by support are two different decisions, and only one of them is what the maintainers ask for.

Pull request titles carry the branch decision: [nomerge] and [backport]

Branch choice is made in the title of the pull request, not at merge time. The rule is to target the oldest branch you would like your changes to end up in, put [nomerge] in the name when a change is version specific and must not travel forward, and put [backport] when the change comes from a newer branch and needs no forward merge. If a change is hard to merge forward, you may be asked to submit a second pull request targeting the newer branch as well. Most changes should go to 2.13.x, and the project says it is increasingly reluctant to accept 2.12.x targets unless there is a special reason such as an especially bad bug or commercial sponsorship.

No merge without a signed CLA

Every contribution is gated on paperwork before code is discussed. The project requires that you sign the Scala CLA before any of your work can be merged, stated as protection of Scala's future as open source software, and the signing link lives at cla.scala-lang.org. Alongside that, issue and bug reports for Scala 2 belong in the scala/bug tracker rather than in this repository, and that tracker carries good first issue and help wanted labels for people looking for something to pick up. Broader efforts are coordinated on a separate scala/scala-dev tracker. The consequence for an organization sending patches is a legal step that sits ahead of the engineering work. The four step path is: find or file an issue in scala/bug, fork scala/scala, push a branch, then open the pull request.

Building takes two passes, and CI still checks Java 8

A Scala build is bootstrapped, which means it is not a single compilation. During ordinary development a new build is produced by the previously released version, known as the reference compiler, or STARR for short, and building with STARR is enough for most kinds of change. A full build adds a second step: build again using the freshly built compiler. On the toolchain side, a Java SDK is required with a baseline of 8 for both the 2.12.x and 2.13.x branches, and later SDKs such as 17 or 21 are fine for local work, but CI verifies against the baseline version, which means your machine and the build server can disagree without you noticing. sbt is the other required tool. macOS and Linux work; Windows may work if you use Cygwin, and the project asks for community help documenting whatever setup Windows needs. The consequence is that a green local build says less than it appears to, and Windows contributors carry the undocumented setup burden themselves.

Three test stacks, one of them written in this repository

The test tree is split three ways and the layout is published in the README as the primary map of the repository:

scala/
+--build.sbt                 The main sbt build definition
+--project/                  The rest of the sbt build
+--src/                      All sources
   +---/library              Scala Standard Library
   +---/reflect              Scala Reflection
   +---/compiler             Scala Compiler
+--test/                     The Scala test suite
   +---/files                Partest tests
   +---/junit                JUnit tests
   +---/scalacheck           ScalaCheck tests
+--spec/                     The Scala language specification

JUnit and ScalaCheck are familiar, while Partest is Scala's own internal parallel testing framework and comes with a helper java agent. That means a bug report has a better chance of being actionable when the reporter knows which framework covers the failure area, since the tests under files are driven by a harness maintained in the same tree as the compiler. Two maintainers are listed for partest specifically, alongside their other areas. The consequence for a reporter is small but real: this repository does not funnel everything through one runner, so a reproduction that skips the harness will not be comparable to the results the maintainers see.

IDE and Scala.js tooling consume what this build emits

The second half of the repository layout exists to serve clients outside the compiler:

scala/
   +---/library-aux          Scala Auxiliary Library, for bootstrapping and documentation purposes
   +---/interactive          Scala Interactive Compiler, for clients such as an IDE (aka Presentation Compiler)
   +---/manual               Scala's runner scripts "man" (manual) pages
   +---/partest              Scala's internal parallel testing framework
   +---/partest-javaagent    Partest's helper java agent
   +---/repl                 Scala REPL core
   +---/repl-frontend        Scala REPL frontend
   +---/scaladoc             Scala's documentation tool
   +---/scalap

The interactive directory is the Presentation Compiler that IDEs drive, and the maintainer list names a dedicated owner for interactions with Scala.js and another for the TASTy reader, the format Scala 3 tooling consumes. library-aux exists for bootstrapping and documentation purposes. The consequence for a contributor is that changes here are not consumed only by this repository: a change to the presentation compiler, the REPL frontend or the TASTy reader path reaches editor plugins and the Scala.js toolchain, and the people who own those readers are the ones who will judge the change.

Maintainers are addressed by area, not by queue

Instead of a general call for help, the README publishes a table mapping usernames to areas, and an invitation to ask a specific person directly by mention when a pull request needs help. The areas are narrow enough to be useful: one maintainer takes the back end, optimizer, named and default arguments, and reporters; another takes compiler performance, weird compiler bugs and lambdas; another covers getting started, build, CI, community build, Jenkins, docs, library and REPL; the pattern matcher, MiMa and partest work sits with one person; warnings, lints, errors, REPL, compiler options and compiler internals sit with another. Collections library and performance, concurrency and futures, higher-kinded types, implicits and variance each have an owner too. The consequence is practical on both sides: a contributor can route a question to the one person who knows it, and a maintainer reviewing a binary compatibility change knows that MiMa is one person's domain rather than an undifferentiated queue.

Top-level files the structure listing never mentions

The README's structure section covers build.sbt, project/, src/, test/ and spec/, and a second listing covers library-aux, interactive, manual, partest, partest-javaagent, repl, repl-frontend, scaladoc and scalap. The repository root holds more than that map shows: .scala-steward.conf, versions.properties, .jvmopts, .mailmap, AGENTS.md, LLM_POLICY.md, CODE_OF_CONDUCT.md, SECURITY.md, NOTICE, LICENSE, Gemfile, gitconfig.SAMPLE, plus admin/, doc/, scripts/ and tools/ directories. The structure listings do not explain these files, so a contributor interested in version settings or dependency updates should open versions.properties and the Scala Steward configuration directly.

Editorial conclusion

Scala 2 is a maintenance-mode language with a live repository, so choose a branch deliberately: 2.13.x is where changes land, and 2.12.x is under minimal maintenance even though it produced the most recent release, v2.12.21 on 2025-12-08. Contributors should plan for a bootstrapped full build that compiles first with the previously released compiler (STARR) and then again with the freshly built one, a Java 8 baseline that CI checks even when your local JDK is 17 or 21, a signed CLA before any merge, and Cygwin if you build on Windows. Anyone who wants an installer, a command line tool, or Scala 3 language work should not start here, since the README opens by saying this is Scala 2, sends Scala 3 readers to the scala/scala3 repository, and documents building the compiler from source rather than installing a distribution.

Frequently asked questions

Official sources

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