8 ms·

My biggest problem with .NET, is how fast it's moving. Slow down! Also increase LTS support timelines. Default is 3 years, which is just not enough. Ubuntu LTS

My biggest problem with .NET, is how fast it's moving. Slow down! Also increase LTS support timelines. Default is 3 years, which is just not enough. Ubuntu LTS is the model to follow. https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core https://dotnet.microsoft.com/en-us/platform/support/policy/d... We've still got code running on .NET Framework 4.8 (supported, I think?) We've still got code running on .Net Core 3.1 (now out of support) We are moving to .NET 6, but given our own 6 month release cycles, and layoffs, I'm not sure we can keep up.

skeeter2020 4y ago
Agreed! the move from 2.x to 3.x was pretty easy, but going to 6.x was painful, and why have a LTS that lasts only slightly longer than the follow-on 7.x version? Half of each cycle we don't know if we should update, to which version, or just wait.
mikece 4y ago
I'll second the request for increasing the length of LTS! While it's technically 36 months it turns out to be 24 to 28 months in practice because my shop will not upgrade our projects immediately -- and we do have to update our projects since we have a TON of AWS lambda functions in C#. After the last "Oh crap, the deadline to upgrade" death march we started having serious discussion about dropping C# for new lambda development and going with Python. If the LTS were extended to at least 5 years, or there was some sort of bug-fix-only support beyond the current 3 year TLS then the ground-swell toward python where I work would stop.
- achr2 4y ago
  What issues are you seeing? .Net (to IMHO its detriment) has incredibly few breaking changes from release to release.
  - mikece 4y ago
    It's not that things break when upgrading, it's that we need to call a halt to new feature development and go upgrade all lambda runtimes before the deadline because AWS won't support deploying lambdas running deprecated .NET Core versions. In the last couple years we've had to stop everything to make sure all of our 2.x code was up to 3.1 (6 wasn't out quite yet) and a year alter we moved everything up to net6 to stay within the AWS deployment support.
pathartl 4y ago
I think these are just growing pains. The migration from 6 to 7 to 8 is going to be more fully representative of how .NET is going to work. There was a lot of stuff with Core 2/3 that wasn't fully fleshed out and is generally why we avoided building anything in it. And yes, 4.8 is still getting security updates, but .NET 4.x is effectively dead and almost no new projects should be built in it (yes Winforms people I hear your screams)

skeeter2020 4y ago

Agreed! the move from 2.x to 3.x was pretty easy, but going to 6.x was painful, and why have a LTS that lasts only slightly longer than the follow-on 7.x version? Half of each cycle we don't know if we should update, to which version, or just wait.

mikece 4y ago

I'll second the request for increasing the length of LTS! While it's technically 36 months it turns out to be 24 to 28 months in practice because my shop will not upgrade our projects immediately -- and we do have to update our projects since we have a TON of AWS lambda functions in C#. After the last "Oh crap, the deadline to upgrade" death march we started having serious discussion about dropping C# for new lambda development and going with Python. If the LTS were extended to at least 5 years, or there was some sort of bug-fix-only support beyond the current 3 year TLS then the ground-swell toward python where I work would stop.

achr2 4y ago
What issues are you seeing? .Net (to IMHO its detriment) has incredibly few breaking changes from release to release.
- mikece 4y ago
  It's not that things break when upgrading, it's that we need to call a halt to new feature development and go upgrade all lambda runtimes before the deadline because AWS won't support deploying lambdas running deprecated .NET Core versions. In the last couple years we've had to stop everything to make sure all of our 2.x code was up to 3.1 (6 wasn't out quite yet) and a year alter we moved everything up to net6 to stay within the AWS deployment support.

pathartl 4y ago

I think these are just growing pains. The migration from 6 to 7 to 8 is going to be more fully representative of how .NET is going to work. There was a lot of stuff with Core 2/3 that wasn't fully fleshed out and is generally why we avoided building anything in it. And yes, 4.8 is still getting security updates, but .NET 4.x is effectively dead and almost no new projects should be built in it (yes Winforms people I hear your screams)