Change in F# branching strategy #18731
Description
TLDR
If you are a feature contributor, nothing changes. Just keep raising PRs to main.
If you create a new LanguageFeature, it shall be mapped to vNext instead of preview if it is considered stable.
Context
Branching
This repository was using release release/* branches for two purposes:
- Servicing branches for already released versions of the products (.NET SDK, Visual Studio, nugets).
- A "future" branch for a not-yet released version of the product, the next major version of the products.
Development went via main, but all insertions into the products happened via the future branch.
Alignment
The branching strategy with a future branch was not aligned with rest of .NET. This was mostly visible in the virtual mono repository for full .NET at dotnet/dotnet. All other components were flowing their main into it, but F# was flowing the future branch there.
The Change
Starting from today, dotnet/fsharp gets aligned with other .NET components and will only use release branches for servicing. The next major release will be implicitly covered by main.
This means that preview versions of .NET SDK or Visual Studio will also get served by this repository's main and no longer a release branch. This will also speed up the feedback loop by eliminating the step of a bot merging changes from main to release branch.
When to use servicing release/* branches
The servicing branches are still relevant for bugfixes that should go into servicing releases of the products (e.g. into 9.0.303 version of the .NET SDK, which is a servicing release for .NET 9).
The right branch target can be either selected upfront, or used via backporting after the change lands in main first.
When is a new release/* branch created
main will always carry the meaning of next major version. Once development for that major releases freezes (let's say for .NET 10), a servicing branch for the just closed version gets created and will be open for contributions which are relevant for servicing (= bugfixing only, no new features).
Language Features
With main always having the meaning of upcoming major version, all new language features can be mapped against it. The user will go trough an explicit act of using a preview version of the SDK, and will not need to also map a LangVersion element in the project in order to dogfood new features. The community of contributors should therefore get more testing exposure for newly introduced features.
In the event of breaking changes, the option to downgrade a project level LangVersion will still be there.
The preview language version mapping shall be still used for features that are not considered finished or stable.
TLDR for language features
The default for users of preview .NET SDK versions changes to get all new language features without another explicit act. Before this change, users needed to BOTH download a preview SDK AND reconfigure the project.
Fineprint
This change might affect you if you are using any repository-level automatism and relied on the existence of future-version branches. Please reach out to us if this breaks any existing use cases.