Add a document describing release cycle and backporting criteria.

[Kordyjan]

This document specifies the new release cycle and criteria for backporting PRs from the main branch to the LTS line.

The backporting flowchart was discussed before. I think it reflects the compiler team's consensus.

The release cycle part is new, and I'm looking forward to feedback.

[odersky]

Let me sum up the comments I made during the last meeting:

First, I think we should have RCs for all Next releases, and revert back to the train model, which worked well for us in Dotty.
Advantages are:

• It is clear for everyone when a new release is cut, and rare enough to be easily remembered.
• We have ample space (a full 6 weeks) to revert anything in a RC if it breaks something, either in the open CB or as reported by early testers.
• The tweak that only minor releases need RC's is a needless complication since it introduces irregularities.
• For users it's not always clear what the difference is. A critical bug fix (for them) might land in a patch release, but they would still be interested in getting this early in an RC and trying it out.

For all these reasons I think it's simplest to revert a train model with a 6 weeks period. This means:

• At day 0, we turn main into RC1, and the previous RCx becomes final.
• If there is a critical bug to revert in the following 6 weeks we create a new RC. This does usually not reset the clock, except if the RC is created in the last week of the cycle.
• 6 weeks later the process repeats with the next version number.
• At the time we create an RC, we decide whether it should be a patch release or a minor release depending on what has been merged into main. (there will be clear communication, e.g. using a PR label before a change requiring a minor release is merged).

Second, I think we should better decouple LTS and Next releases. There's no need that they follow the same tight schedule. Motivation: For an LTS release we want to make very sure there are no regressions. This might mean we need more time for a final release, which is OK. Our experience with 3.3 releases has shown us that we almost always need more time. But that delay should not impact Next releases, which should proceed like clockwork.

[Kordyjan]

After discussions summarized by Martin's comment, we decided to decouple the Next and LTS release cycles.

The only part that may be controversial now is

If there is less than a week left before the release, and the last RC still contains critical bugs, the compiler team may decide to postpone publishing the stable version. There will always be at least one whole week between publishing the last RC and promoting it to the status of a stable release. This delay doesn't affect the RC-1 date for the next version. It will be released six weeks after the previous version's RC-1. The goal is to ensure that delay in releasing one version doesn't cause future releases to be larger in terms of the number of merged PRs, as it can make regressions inside of them more complex to pinpoint and fix, leading to the accumulation of delays for future versions.

I think that this accumulation of delays is what has been happening since 3.2.0 and was especially visible during the release of 3.3.1.

[SethTisue]

This does a good job laying out the what. I feel it's short on why. You give answers, but isn't clear what the questions were. What prompted this? Why is this changing now? Was something actually different before, or are we just being more explicit and clear now about existing practices? What were the problems that needed to be addressed?

[SethTisue]

Suggested change

	Since Scala 3.3.0, there are always two versions of Scala 3 being developed at the same time: Scala Next and Scala LTS.
	Since Scala 3.3.0, there are always two versions of Scala 3 being developed at the same time: Scala LTS (currently 3.3.x) and Scala Next (will be 3.4.x, 3.5.x, and so on, until a new LTS is designated). This scheme was previously outlined in [this August 2022 blog post](https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html).

[SethTisue]

At this point you will probably have lost many of the more casual followers of the blog, as the preceding section are flowchart were quite in-depth.

I would suggest also including the most important top level takeaways from this section, such as "Scala Next strictly follows a six-week release train model", in the intro to the blog post.

I would suggest reviewing the intro and asking yourself, “What if the reader only reads the introduction? Would they be missing anything vital?"

[Kordyjan]

This does a good job laying out the what. I feel it's short on why. You give answers, but isn't clear what the questions were. What prompted this? Why is this changing now? Was something actually different before, or are we just being more explicit and clear now about existing practices? What were the problems that needed to be addressed?

@SethTisue: The goal is to have a written record of the current consensus of the compiler team about how the releases should look after 3.3. In the past, backporting and release procedures were more of an oral tradition than something transparent and well-known, even for the people working directly in the compiler. I wanted to have those things written down somewhere in the compiler repo so we can direct people there in case of questions.

This is not a blog post. We will probably have a post about the backporting and the new release cycle around the release of 3.4. It will explain why more than what and point readers curious for details to this document.

[SethTisue]

This is not a blog post

You called it — I thought I was reviewing a blog post 🤦

We will probably have a post

👍

[JD557]

This link gives me a 404.

Maybe the project is private? If that's intended, I think it would still be nice to disclose that.

[Kordyjan]

I can open it in private browser window, so it shouldn't be private now.

[JD557]

I can confirm that I do see it now 👍