F# 6, 7 compatibility

[auduchinok]

We're getting both internal and external reports about missing F# 6 and 7 compatibility since the latest Rider release because of #19143.

The older language versions support was removed too abruptly for our users, as they weren't notified in advance and couldn't prepare for it accordingly.

Looking at the changes it seems that the removal didn't bring much value as is and at the same time it has definitely made it worse for users who weren't prepared for that.

I propose we:

• revert the language version support removal or improve how we handle projects using older versions
• add a warning about a (possible) future removal when an older language version is used
• decide on a date when/if it's going to be done (and give at least one year notice to the users)

[T-Gro]

Is this an IDE tooling problem?

The .NET 10 released in autumn 2025 still carries the support, and picking an SDK is the explicit action users can do.

Also, are there features beyond mlcompat (which was producing a warning for a long time) whose stabilization/ making them non-optional/... that are subjects of the complains?

[T-Gro]

Also "feature removal" is not the intent, this should really be seen as turning proven (4 versions in) features into a core part of the language.

I agree "Remove ML Compat" was a special feature in that way, but that is also why it had delicate care and a long way to adapt.
Hence my interest in learning if there are other features causing an issue for people.

[auduchinok]

Is this an IDE tooling problem?

Yes. After releasing Rider with a newer FCS, complaints started to appear. I guess the issue is there was a warning about particular language features, but there was newer a warning about language version. I think we should've made a warning about using the language version first and also gave a clear deadline like "Starting in 2027, F# 7 is not going to be supported", so people could prepare.

Also, are there features beyond mlcompat (which was producing a warning for a long time) whose stabilization/ making them non-optional/... that are subjects of the complains?

Using an older version causes errors like this:

Even if support for some older features is removed, we could try to make it work nicer.

[T-Gro]

Ok.
We are not putting the mlcompat code back in main, that is for sure - it will remain available via the already published .NET 10 SDK.

I do not oppose a second layer of the langversion check:

• error on hardly stabilized language features (as is now, means branching code can be removed and feature is baked in without any langversion checks)
• 1 year ahead warning for langversion which is exactly the minimum support (code still available in main of this repo)

If there are specific reasons why people cannot move from 6.0 higher up, it would be great to collect them (I can create "langversion-6-migration-blocker" etc. labels here, to make them easier to track)