Any production project, especially with that sort of rigor, should be sticking to the LTS releases. IMO there is no project that should be on 7 with no plans to upgrade to 8 after it’s released.
If a version upgrade is out of scope, then it should’ve been built on 6 to begin with.
Any production project, especially with that sort of rigor (…)
There is no rigour. There is semantic versioning, patch/bugfix releases, the understanding that stability trumps the latest and greatest, and not having an infinite budget to perpetually work on maintaining projects with unbounded resources, including full regression tests.
Those who care about what they deliver also care about stability.
If a version upgrade is out of scope (…)
It’s a major version bump, which is expected to include breaking changes. Professional teams are mindful of resource allocation. Not everyone works exclusively on personal projects.
do you even .net? “stability trumps the latest and greatest”, that’s exactly what who you’re replying to said. If one is making the choice to use 7 in the context of stability, then one has already planned an upgrade to 8 upon release; otherwise stick to 6.
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?
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.
Any production project, especially with that sort of rigor, should be sticking to the LTS releases. IMO there is no project that should be on 7 with no plans to upgrade to 8 after it’s released.
If a version upgrade is out of scope, then it should’ve been built on 6 to begin with.
There is no rigour. There is semantic versioning, patch/bugfix releases, the understanding that stability trumps the latest and greatest, and not having an infinite budget to perpetually work on maintaining projects with unbounded resources, including full regression tests.
Those who care about what they deliver also care about stability.
It’s a major version bump, which is expected to include breaking changes. Professional teams are mindful of resource allocation. Not everyone works exclusively on personal projects.
There is no way around this.
do you even .net? “stability trumps the latest and greatest”, that’s exactly what who you’re replying to said. If one is making the choice to use 7 in the context of stability, then one has already planned an upgrade to 8 upon release; otherwise stick to 6.
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?
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.