Not really. Stability does not mean consuming a package that’s supported for a long time. Stability is a function of the work you put into your project. You can consume all the LTS stuff you can think of, and still release an unstable mess.
In this case, being forced to undergo a major version upgrade without being able to do full regression tests is exactly how you get your projects to break, no matter how many LTS dependencies you consume.
The whole point of this thread is that it’s preferable to consume bug fixes in patch releases than being forced to undergo major version upgrades. Do you disagree?
being forced to undergo a major version upgrade without being able to do full regression tests is exactly how you get your projects to break, no matter how many LTS dependencies you consume
that’s exactly what’s already being said. First, there’s only one LTS change even being discussed, e.g. no one is talking about moving from 6 to 8 or back porting from an upcoming 8 to 6. Second, if your not going to be bothered with the very preparations your mentioning should be made when choosing 7, then one should choose 6.
The whole point of this thread is that it’s preferable to consume bug fixes in patch releases than being forced to undergo major version upgrades. Do you disagree?
Fundamentally, if I enter into a contract of using 7 then I understand sets of bugfixes won’t necessarily be back ported.
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?
Yes, I do. Do you?
Not really. Stability does not mean consuming a package that’s supported for a long time. Stability is a function of the work you put into your project. You can consume all the LTS stuff you can think of, and still release an unstable mess.
In this case, being forced to undergo a major version upgrade without being able to do full regression tests is exactly how you get your projects to break, no matter how many LTS dependencies you consume.
The whole point of this thread is that it’s preferable to consume bug fixes in patch releases than being forced to undergo major version upgrades. Do you disagree?
that’s exactly what’s already being said. First, there’s only one LTS change even being discussed, e.g. no one is talking about moving from 6 to 8 or back porting from an upcoming 8 to 6. Second, if your not going to be bothered with the very preparations your mentioning should be made when choosing 7, then one should choose 6.
Fundamentally, if I enter into a contract of using 7 then I understand sets of bugfixes won’t necessarily be back ported.
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?