scala/scala: What the Scala 2 Repository Actually Contains

What scala/scala Is, and Who Should Read It

Scala 2 is a JVM language that mixes functional and object-oriented programming, and this repository is where its standard library, compiler and language specification live. The README opens with exactly that framing and then does something useful: it sends you elsewhere. Scala 3 lives at scala/scala3, and issues for Scala 2 live at scala/bug. If you arrived here looking for a bug tracker, you are in the wrong repository by design.

The audience splits cleanly. Library maintainers who need to know why a collection method behaves the way it does will read src/library. People debugging a compiler crash will read src/compiler. Anyone writing application code against Scala 2.13 will mostly consume published artifacts and never touch this tree. The repository is not a product page; it is the source of record for a language implementation that other people package and distribute.

How the Scala 2 Tree Is Laid Out

The README gives the layout directly. src/library holds the standard library, src/reflect holds reflection, and src/compiler holds the compiler. Tests are split three ways under test/: test/files for Partest tests, test/junit for JUnit, and test/scalacheck for ScalaCheck. The language specification sits in spec/.

Beyond those, the tree carries components that surprise people who assume a compiler is one program. library-aux exists for bootstrapping and documentation. interactive is the presentation compiler that IDE clients drive. repl and repl-frontend split the REPL core from its frontend. scaladoc, scalap and partest are separate tools living in the same tree, and testkit is a unit-testing kit. The build itself is sbt: build.sbt is the main definition and project/ holds the rest.

That structure explains a recurring confusion. When someone says the Scala 2 compiler is slow or the REPL behaves oddly, the relevant code may be in repl/, not src/compiler. Reading the layout before filing a patch saves a wasted pull request.

Building Scala 2 from build.sbt

The README points at the build section for setting up your machine, and the repository confirms sbt as the build tool through build.sbt and the project/ directory. A .jvmopts file is present at the top level, which is where JVM flags for the build are configured. The README does not print a full build command in the text available here, so treat the following as the standard sbt entry point rather than a quoted recipe.

sbt

Running sbt at the repository root loads build.sbt and drops you into the sbt shell, where the subprojects listed in the layout become available. If you intend to work on the standard library, the src/library directory is the one to open first, and test/junit is where unit-level tests for it live.

For contributing, the README states the workflow plainly: find or file an issue in scala/bug, fork scala/scala, push to a branch in your fork, and open a pull request. It also states that you must sign the Scala CLA at cla.scala-lang.org/scala/scala before any work can be merged. That is a gate, not a formality, and it applies to every contributor.

Branch Policy: 2.13.x Is Where Work Goes

The default branch is 2.13.x, and the README is explicit that most changes should target it. The 2.12.x line is described as under minimal maintenance, and the README says the project is increasingly reluctant to accept 2.12.x changes unless there is a special reason, naming an especially bad bug or commercial sponsorship as the examples.

Two PR naming conventions matter. If your change is version-specific and should not be merged forward, put [nomerge] in the PR name. If it is a backport from a newer branch and therefore needs no forward merge, put [backport] in the name. Merging happens periodically from 2.12.x to 2.13.x, so a change targeting the older branch may be asked for again as a separate PR against the newer one.

This is a real constraint on contribution strategy, not a formality. A fix that only makes sense on 2.12.x has a narrow path to acceptance, and the README says so before you write the patch.

The Bug Tracker Is Not in This Repository

The single most common wrong turn with scala/scala is filing an issue here. The README states that issues and bug reports for Scala 2 are located in scala/bug, and that tracker is also where new contributors find work through the good first issue and help wanted labels. Broader coordination happens on scala/scala-dev.

The practical consequence is that a GitHub issue opened against scala/scala may sit unattended while the maintainers watch a different queue. If you are evaluating the project's responsiveness, the issue counts on this repository tell you nothing useful, because the active tracker is elsewhere. That is a deliberate split, and the README explains it in the first screen of text rather than burying it.

For a first contribution, the README suggests the reverse order too: submitting a well-documented pull request right away is acceptable, rather than waiting for an issue to be filed first.

Where Scala 2 Sits Against Scala 3

The README's first line after the title is a redirect: for Scala 3, visit scala/scala3. That is the honest alternative, and the difference is not cosmetic. Scala 3 is a separate repository with a separate compiler, and the two lines evolve independently. Scala 2 remains the target for codebases that depend on macros, on libraries that have not crossed over, or on tooling built against the 2.x compiler internals.

The release cadence visible here shows both lines alive. v2.13.18 was released on 2025-11-17, v2.13.17 on 2025-09-30, and v2.12.21 on 2025-12-08. So 2.12 is not frozen, despite being described as under minimal maintenance. It receives releases; it just does not receive the same willingness to accept changes.

Choosing Scala 3 is choosing the newer compiler and leaving this repository behind. Choosing Scala 2 is choosing stability of an ecosystem that still ships. Neither is a default you should pick without checking which of your dependencies have made the move.

Licence, Maintenance and the Cost of Upgrading

The repository is licensed Apache-2.0, with LICENSE and NOTICE files at the top level. Apache-2.0 permits commercial use and modification and includes a patent grant, which matters if you are embedding compiler or library code rather than consuming published jars. This is a description of the licence text, not legal advice; if you are redistributing modified compiler code, read LICENSE and NOTICE yourself.

The last push to the default branch was on 2026-09-09, so the repository is not dormant, and it is not archived. The README does not document a rollback procedure for a bad upgrade, and it does not describe a migration path between 2.12 and 2.13 beyond the merging of branches. Anyone planning a 2.12 to 2.13 move should treat that as undocumented here and look for guidance outside this repository.

Upgrade cost concentrates in the library sources under src/library and in any code touching compiler internals. If you consume Scala 2 through a build tool rather than building from source, your cost is the version bump and whatever your dependencies require, not the sbt build in this tree.

Editorial conclusion

Adopt scala/scala if you are maintaining a Scala 2.12 or 2.13 codebase, need to read the standard library or compiler sources, or intend to send a patch. Do not adopt it if you are starting new Scala work on Scala 3, since the README redirects that audience to scala/scala3. Before you contribute, verify three things: that your change targets 2.13.x rather than 2.12.x, that you have signed the Scala CLA, and that the issue you are fixing exists in scala/bug, because this repository does not host its own tracker.

Frequently asked questions

Official sources

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