Scala maintenance continuity and compiler adoption are separate choices

Scala teams should decide maintenance continuity and compiler-line adoption separately. A new organization taking responsibility for Scala 2 does not force an application onto Scala Next. Choosing between Scala 3.9 LTS and Scala 3.10 requires a second decision about source code, published libraries and the dependency graph the team actually controls.

This November 2026 retrospective looks at two announcements within the week beginning October 7. The Scala 2 maintenance handover is dated October 7. The Scala 3.10 release announcement is dated October 12. Reading them together is useful, provided their different commitments remain separate. Organizational continuity and a newer language line answer different engineering questions.

A handover names responsibility

The October 7 statement says VirtusLab has assumed Scala 2 maintenance, working in coordination with the Scala Center and Scala Core Team. It says former Scala 2 team members have joined VirtusLab and commits to maintaining Scala 2.12 and 2.13 as long as necessary. That is evidence of an announced maintenance arrangement, with people and institutions identified.

For a technical leader, that information is more useful than treating a change of employer as proof that the language line has ended. It supports a continuity discussion with the team responsible for an existing application. It still is a public commitment rather than an application-specific service-level agreement. The phrase “as long as necessary” does not establish contractual response times, a fixed delivery schedule or a remedy for a particular customer's incident.

That distinction affects budgeting. An organization can reasonably continue maintaining a Scala 2 application while preparing a separate modernization plan. Its own responsibilities for dependencies, application defects and deployment remain. Upstream compiler maintenance helps sustain one part of that foundation; it does not take over the application or promise that every library it uses will remain maintained.

Compatibility has several meanings

The October 12 release describes Scala 3.10 as the first Scala Next release. It contrasts that direction with Scala 3.9 LTS and its priority on Scala 2.13 compatibility. It also says binary compatibility with earlier Scala 3 libraries is preserved while source using removed features needs updating. Those statements can coexist because they concern different artifacts and operations.

Using an already compiled library is different from recompiling that library's source. A source migration can be required even when an earlier binary remains usable under the stated compatibility rules. A team should therefore ask which artifact it publishes and which operation it needs to perform. The word “compatible” alone leaves too much unstated to support a release decision.

Cross-compilation adds another obligation. A library serving Scala 2 and Scala 3 consumers must consider what source it can compile for both audiences. Scala 3.10's binary compatibility statement does not promise that new Scala 3 source constructs can be compiled by Scala 2. It also does not guarantee source compatibility for every existing project. Macro and compiler-plugin dependencies deserve attention because they can depend on compiler representations beyond ordinary library use.

Library publishers carry a wider contract

A reusable library has consumers whose toolchain choices its author may not control. Choosing an LTS line can be rational when the publisher's priority is a stable compatibility boundary for those consumers. That decision can preserve time for useful library maintenance instead of making every consumer follow the publisher's preferred compiler immediately. It is a product decision about the library's audience.

A hypothetical application with an internal library has a different boundary. If one team controls every consumer, it may coordinate source changes and compiler choices together. That can make newer language features worth adopting. The condition is control over the relevant dependency graph, including components that cannot simply be rewritten by that team. An application label alone does not prove that control exists.

The strongest case for Scala Next is therefore specific: a feature or simplification that matters to an application, together with a feasible path through its dependencies. A team can rationally choose that benefit over remaining on LTS. The argument weakens if the benefit is merely a newer version number or if essential libraries and compiler extensions have no understood path. No toolchain installation or migration trial is claimed here.

Separate the two decisions in the maintenance plan

Start the Scala 2 continuity decision with the maintenance commitment and the application's own support needs. Document which language line is deployed and what upstream maintenance contributes. If the business needs a contractual response, establish that through an actual agreement rather than extracting an SLA from the public handover post. The organization change supplies context, not a substitute contract.

Then evaluate compiler adoption through a separate account of artifacts and consumers. Identify whether the project consumes compiled libraries, publishes source for others or cross-compiles a shared codebase. Record which dependencies depend on compiler internals. Those facts determine what needs verification before adoption. They cannot be inferred from a blanket promise of binary compatibility.

Keeping the decisions separate also makes postponement meaningful. A team can decide that Scala 2 maintenance is sufficiently understood while a Scala 3 migration remains planned. Another team can already be on Scala 3.9 LTS and choose to defer Next because of its library audience. A third can adopt Next for a controlled application. None of those choices contradicts the maintenance handover.

End with the compatibility promise you can keep

The business result should be a maintenance plan that explains who sustains the current foundation and a release policy that explains what consumers may rely on. Those documents can refer to the same announcements without turning them into the same decision. That separation helps prevent an organizational headline from creating an unnecessary migration deadline.

Software maintenance should make the application's actual obligations visible. Preserve the distinction between an upstream commitment and a purchased SLA, and between binary use, source compilation and Scala 2 cross-compilation. Choose the compiler line whose benefits justify the obligations your team can verify and maintain. A credible compatibility promise is more valuable to consumers than a migration justified only by chronology.