You may actually get the other guys point but it does not sound like it.
Based on Microsoft’s support cycle for .NET releases, if you start a project in .NET 7, you already knew on that first day that you were going to have to upgrade to .NET 8 by May 2024 at the latest as .NET 7 becomes unsupported then. Not just to upgrade, to upgrade to .NET 8 specifically.
I guess you could roll back to .NET 6 until November 2024 but that seems pretty insane. When you choose .NET 7, the choice to upgrade to .NET 8 is baked in before you write a single line of code.
That is why complaining about “being forced to upgrade to 8 instead of sticking with 7” sounds like a weak argument.
If you choose .NET 6, you can stick with it all the way to .NET 9 if you really, really want.
In .NET, even numbered releases are for people that do not want to be “forced to upgrade” and odd numbered releases are for people that want to stay up-to-date with the platform (which means adopting new releases as they come ).
I guess another choice is to use unsupported releases. However, if that is your choice, complaining about a lack of bug fixes in the release you are using is obviously bonkers.
While it is a bit aggressive, the question “do you even .net” is, I think, questioning if you understand the .NET release cycle and the implications of choosing one release over another when you start a project.
Taking a step back, it makes a whole lot of sense that Microsoft would be putting their bug-fixing energy into .NET 8. After all, as an LTS release, some people may choose to stick with it until .NET 11 is out in November 2026. If you are going to invest in fixing bugs, would you choose the release that almost everybody is going to stop using in November 2023 or the one that many projects will use for 2 - 3 years longer than that?
You may actually get the other guys point but it does not sound like it.
Based on Microsoft’s support cycle for .NET releases, if you start a project in .NET 7, you already knew on that first day that you were going to have to upgrade to .NET 8 by May 2024 at the latest as .NET 7 becomes unsupported then. Not just to upgrade, to upgrade to .NET 8 specifically.
I guess you could roll back to .NET 6 until November 2024 but that seems pretty insane. When you choose .NET 7, the choice to upgrade to .NET 8 is baked in before you write a single line of code.
That is why complaining about “being forced to upgrade to 8 instead of sticking with 7” sounds like a weak argument.
If you choose .NET 6, you can stick with it all the way to .NET 9 if you really, really want.
In .NET, even numbered releases are for people that do not want to be “forced to upgrade” and odd numbered releases are for people that want to stay up-to-date with the platform (which means adopting new releases as they come ).
I guess another choice is to use unsupported releases. However, if that is your choice, complaining about a lack of bug fixes in the release you are using is obviously bonkers.
While it is a bit aggressive, the question “do you even .net” is, I think, questioning if you understand the .NET release cycle and the implications of choosing one release over another when you start a project.
Taking a step back, it makes a whole lot of sense that Microsoft would be putting their bug-fixing energy into .NET 8. After all, as an LTS release, some people may choose to stick with it until .NET 11 is out in November 2026. If you are going to invest in fixing bugs, would you choose the release that almost everybody is going to stop using in November 2023 or the one that many projects will use for 2 - 3 years longer than that?