Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET 9.0 support strategy #16985

Closed
sebastienros opened this issue Nov 10, 2024 · 14 comments
Closed

.NET 9.0 support strategy #16985

sebastienros opened this issue Nov 10, 2024 · 14 comments

Comments

@sebastienros
Copy link
Member

sebastienros commented Nov 10, 2024

.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
Copy link
Member

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
Copy link
Member

Piedone commented Nov 11, 2024

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

Piedone commented Nov 11, 2024

Yes, since 10 will again be an LTS.

@hishamco hishamco changed the title .NET 9.0 support stragegy .NET 9.0 support strategy Nov 11, 2024
@hishamco
Copy link
Member

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

@MikeAlhayek
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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).

@sebastienros sebastienros modified the milestones: 2.1, 2.x Nov 14, 2024
Copy link
Contributor

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.

1 similar comment
Copy link
Contributor

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.

@MikeAlhayek
Copy link
Member

.net 9 was merged.

@MikeAlhayek MikeAlhayek modified the milestones: 2.x, 2.1.3, 2.1 Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants