.NET 9.0 support strategy

[sebastienros]

.NET 9.0 should be GA on 11/12/2024 (next Tuesday). How do we want to proceed with the merging on the branch?

My suggestion is to

• Update the version and merge to main as soon as it is released?
• Ship 2.1 (we are currently at 2.0.2) since it contains important changes (including net9.0 support) though not breaking? (we are still supporting net8.0)
• Building the solution will require dotnet 9.0 sdk though. Since it's enforced by global.json it will also be a requirement even if you want to build/deploy for net8.0.

An alternative could be to release a 2.1 with the current main branch, and right after a 2.2 so users can still get the current fixed without having to deal with net9.0.

[hishamco]

IMHO no need to rush, so we should focus on quality, .NET 9.0 is a major release we need proper time for testing. I suggest merging 9.0 on the main then it will be a part of 2.1 - if we can defer the release - otherwise we publish 2.1 then 2.2 is the one that targets both .NET 8 & 9

[Piedone]

We should double-target .NET 8 and .NET 9, just as we did with 6 and 7, and how we always target LTS and latest if they're not the same. Then we can release that as 2.1, since it won't be breaking (as a consumer, you can keep using .NET 8).

[MikeAlhayek]

We should double-target .NET 8 and .NET 9, just as we did with 6 and 7, and how we always target LTS and latest if they're not the same. Then we can release that as 2.1, since it won't be breaking (as a consumer, you can keep using .NET 8).

Agreed.

[hishamco]

We should double-target .NET 8 and .NET 9, just as we did with 6 and 7

Once again when we target 10 we will delete the previous one?!!

[Piedone]

Yes, since 10 will again be an LTS.

[hishamco]

Also, we could align OC major release with the LTS version

[MikeAlhayek]

I don’t think we should drop support for .NET 8 in favor of .NET 10 unless there are critical APIs in .NET 10 that we absolutely need. Otherwise, we should continue supporting the lowest version possible. Dropping .NET 8 support would effectively force everyone using Orchard Core to also drop support for it, which could create unnecessary friction.

I’m open to dropping support if there are compelling new APIs in .NET 10 that we must have—similar to how we dropped support for .NET 6 when we gained access to new APIs like ArgumentNullException.ThrowIfNull() and other features introduced in .NET 7 and beyond.

[sebastienros]

Otherwise, we should continue supporting the lowest version possible.

It's a matter of how many versions we want to support. Two seems fine because that's the minimum we can do to always have one LTS.

Dropping the previous LTS is what we have done so far. Upgrading to the new LTS is usually not an issue for OC, since whatever they use that targets the previous LTS will also work with the newer (a library targeting net6.0 still works for net8.0).

So yes, when net10.0 ships next year this is what we'll support as the target TFM. Like what we did last year when net8.0 shipped.

[sebastienros]

Also, we could align OC major release with the LTS version

No. We don't have to. It would just leave us with breaking changes only once a year, on specific dates. We don't have any reason to do so.

[MikeAlhayek]

So yes, when net10.0 ships next year this is what we'll support as the target TFM. Like what we did last year when net8.0 shipped.

Last year, we dropped .NET 6 to take advantage of APIs available only in .NET 7+ and to avoid adding version-specific checks. .NET 8 reaches end of life on November 10, 2026, coinciding with the release of .NET 10, making it logical to discontinue .NET 8 support then, as it will no longer be supported. However, dropping a framework should be part of a major release, as it could introduce breaking changes. We might consider aligning at least one major release with each .NET LTS version.

[sebastienros]

Last year, we dropped .NET 6 to take advantage of APIs available only in .NET 7+ and to avoid adding version-specific checks.

No. We dropped .NET6 for the reasons I explained before. And as a consequence we were also able to do the things you mention.

I agree that dropping a version is breaking. And that we should reflect it. But it shouldn't wait for LTS releases (how I read Hisham's comment, I prefer your version).

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.