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?
Sorry, you either continue to be clueless about the topic or you’re talking about stuff you know nothing about. Anyone who has a production project using 7 and is given the choice between undergoing a major version upgrade or simply go through a patch update, they will always pick the patch upgrade specially if they can’t spare a full regression test. At least anyone who works in a professional setting who knows what they are doing and cares about stability of a production system. There’s no two ways about it.
It sounds you lost track of the discussion. OP clearly pointed out the scenario of being forced to upgrade to 8 instead of sticking with 7.
I don’t think it’s worth to continue discussing this. Apparently you’re arguing without context and in the process talking besides the point.
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?
no kidding, NO ONE is sticking with 7 unless its part of a series of bad choices
Sorry, you either continue to be clueless about the topic or you’re talking about stuff you know nothing about. Anyone who has a production project using 7 and is given the choice between undergoing a major version upgrade or simply go through a patch update, they will always pick the patch upgrade specially if they can’t spare a full regression test. At least anyone who works in a professional setting who knows what they are doing and cares about stability of a production system. There’s no two ways about it.