Specify the support policy for organization projects

[reardonj]

Seeking Advice

This issue is here to invite discussion, especially from @typelevel/maintainers , @typelevel/tsc , @typelevel/board and interested users on defining what exactly the maintenance backstop is and how we manage Scala 3 LTS transitions, such as the upcoming 3.9 release.

Context

The foundation vaguely indicates that for organization projects it "backstops maintenance of the project, by controlling the group id"

Recently on Discord, kubukoz was inquiring about "which LTS libraries are going to use once another one pops up?"

Action

I think the @typelevel/board to adopt a specific policy so users of org libraries can have some idea exactly what the foundation's maintenance backstop looks like. This relates to the LTS target for organization libraries, as when core projects (eg. cats) move to a new Scala 3 LTS, patches for the latest version can no longer be released for older Scala 3 versions, effectively ending support unless older minors are maintained.

Policy Suggestion

To start discussion, a policy like this should be fairly straightforward:

1. The Typelevel Security Team accepts security reports on behalf of all organization projects and ensures security releases are made for supported organization project versions in a timely manner.
2. Choice of supported platforms, JVM and Scala versions for organization projects is determined by each project's maintainers.
3. The Typelevel Foundation ensures that security releases can be made for the most recent minor[^] release of all maintained organization projects and publishes security releases for these versions on behalf of the maintainers when necessary to make timely security releases.
4. The Typelevel Foundation ensures that security releases for core ecosystem libraries which support Scala 3 can be made for the latest minor version that supports the oldest active Scala 3 LTS version.
5. When a project is retired, the foundation ensures that an announcement is made and the project documentation clearly updated to indicates if/when support will cease.

Notes

1. The security team accepting reports for org projects is hopefully not controversial as it is suggested by the policy on the website already.
2. This is just restating status quo, but included to make it clear that the maintainers determine in general what they are targeting for development. The foundation's backstop is intended to address bus factor concerns, not control project development
3. This is specifically calling out that the foundation will step in for the current version of projects if needed, as it, we are not going to offer to release a fix for eg the cats-effect 3.2.x at this point, but certainly would for the current (as of this writing) 3.7.x branch. Stated differently: if you keep your libraries up to date, you can be sure there will be security patches.
4. The Scala 3 LTS support might be a little more involved. My intent here is to make sure that the foundation supports Scala 3 LTS versions up to EOL, so anyone relying on the minimum maintained version from the Scala Centre can also rely on TL libraries. That said, some organization libraries may not be able to target the oldest LTS¹, but the core libraries needed to develop a TL application do not move that quickly. This would mean potentially maintaining two branches for some projects during the LTS support overlap. Maybe it would be easier to stay on the oldest LTS until it is EOL. Projects on this list would look at least something like these [and any dependencies of those I'm missing]:
   • cats
   • cats-effect
   • fs2
   • log4cats
   • otel4s
   • discipline
   • ScalaCheck
   • Weaver
   • http4s
5. Maybe retirement should have specific timelines? I haven't put anything on here about maintenance of older majors (e.g. cats-effect 2.x, or more topically skunk 1.0.0). Maybe that should be treated the same as retirement?

Explanation of Scala 3 LTS Release Support

Scala 3 has Long Term Support releases every few years. When a new Scala 3 LTS branch is released, the previous branch remains supported for ~1 year after. The Scala Centre recommends that application developers target the latest Scala version, and that library authors should target the LTS, but more conservative application projects are likely to target the LTS anyways.

Since there wasn't been an LTS migration yet, it remains to be seen if downstream users will actually upgrade to supported Scala versions.

Footnotes

1. I don't know if that is the case presently, but certainly I could imagine this happening, especially for newer libraries. ↩

[reardonj]

Another detail on Scala 3.9. It will only support JDK 17+ so when libraries move there, Scala 3 support for older JDKs will end.

[rossabaker]

I plan to treat it like Java: support the oldest living LTS until it is EOL or my hand is forced (usually by a dependency), and then bump.

[reardonj]

I haven't seen a lot of feedback. Though the topic has tangentially come up in some Discord chats around various Scala/JVM version updates. Seeing as we are probably only really are worried about security updates, and for most projects, that isn't really likely, the policy proposal could be simpler:

---

1. The Typelevel Security Team accepts security reports on behalf of all organization projects and assists maintainers to ensure that security releases are made in a timely manner. When maintainers are unavailable, the security team will publish releases on their behalf.
2. Security releases will be made for the following versions of active projects:
   • The most recent minor release
   • The most recent minor release of the previous major version, for one year after a new major version is published
   • The most recent minor release supporting a retired target platform for one year following the retirement of support for that platform by the project
3. When a project is retired, the foundation ensures that an announcement is made and the project documentation is clearly updated to indicates when support will cease. The foundation ensures that security releases for retired projects can be made for a year following retirement.

---

To keep the focus on security guarantees, I have not mentioned who picks the supported platforms or bothered to put anything about how the foundation would deal with losing all the maintainers of a project. I've folded in all the stuff about Scala 3 and JVMs to simply guarantee support for the last release on a dropped platform for one year, to align with the Scala 3 LTS retirement schedule. I am no longer singling out a specific group of projects for that support since, practically, a lot of projects are unlikely to ever need a security release. The ones that are riskiest (i.e. anything that opens a server socket really, eg. http4s, fs2-io) would be on the list anyways.

I'll leave this open for another week in case there are comments on this version.