📢dotnet/runtime schedule for the remainder of .NET 7

[danmoseley]

It's about 4 months until .NET 7 ships ("GA") in November. dotnet/runtime will be following the same procedure that we did for .NET 6, as follows --

• 12-July -- we branched main for Preview 7 and the team has now changed focus from feature development to open bug fixing for .NET 7
• 15-Aug -- we branch main for RC1. After this point, main will be a .NET 8 branch. We will selectively backport fixes to the .NET 7 release branch as needed, with a process similar to the one we use for servicing (but a little more freely). Many or most changes in main will not be backported. No features will be backported.
• 13-Sept -- we branch our release branch for RC2. Nothing changes for those working in main. The bar for changes to be ported into .NET 7 becomes considerably higher (centralized permission process of taking to .NET tactics meeting)
• 10-Oct -- last ship stopper fix merged if any.

Where do community changes go? main remains open at all times for community changes, even adding new approved API. Many will get into .NET 7 if they go in before 15-Aug. However if a change brings too much risk we will hold merging it until 16-Aug.

TLDR: if you plan to work on a change that you want in the .NET 7 product, 15-Aug is the date it needs to be merged by.

Nearer the fall, we'll start thinking and planning for .NET 8, and we'll be sharing our thinking when we do.

[danmoseley]

During this process we are monitoring issues by area that have the .NET 7 milestone, much as we did for .NET 6. Below is a snapshot from earlier in the week. We will be taking each issue and either fixing it, closing it, or setting to the Future milestone (meaning discussion is worth continuing, or we would accept a change for it, but we haven't made a commitment to make the change ourselves).

"ZBB" in the diagram is an old Microsoft term (zero bug bounce) meaning the point where we aim to get zero bugs in the milestone. It's called a bounce as inevitably some must fix bugs are discovered after that point.

[danmoseley]

How are we choosing what to fix? We use criteria like the following to decide what to fix in the remaining time:

1. Broken or significantly incomplete 7.0 scenario
2. Resolves significant customer feedback on 7.0 feature
3. High impact regressions from last release
4. Significant reliability issues
5. Unapproved significant compatibility breaks
6. Breaking PR validation or infrastructure
7. Significant unapproved performance regression from last release
8. Anything we would service for such as security.

As we go along the criteria become increasingly stringent in order to minimize the risk of introducing new issues.

Issues that can't be fixed will be closed or set to Future for further discussion or future work.

[jeffschwMSFT]

[jeffschwMSFT]

[danmoseley]

@VincentBu please leave pinned

[jeffschwMSFT]

[jeffschwMSFT]

[danmoseley]

@jeffschwMSFT not sure how to get this issue itself out of your stats.

[jeffschwMSFT]

:) there is not a way, it will just be part of our non-product issues. We have a lot of samples, docs, etc. that we track towards the end of the release that hang around.

[danmoseley]

On 5pm PDT on Monday 15th, main will become a .NET 8 branch. (moved from Fri to Mon) Here is where we are at:

[jeffschwMSFT]

[jeffschwMSFT]

[jeffschwMSFT]

[jeffschwMSFT]

[jeffschwMSFT]

[danmoseley]

Linking issuesof query for the ~50 remaining (although someone said Github issue search allows "or" now?)
https://issuesof.net/?q=is%3Aopen%20is%3Aissue%20repo%3Aruntime%20%28milestone%3A7.0.0%20or%20label%3Ablocking-release%29

[jeffschwMSFT]

[jeffschwMSFT]

[jeffschwMSFT]

Last update for .NET 7. On our way to GA