3 ms·

I would say it’s completely ok to break backwards compatibility every 20 -30 years as is the case with .NET. Breaking compatibility to consolidate and forward p

by dagaci 2y ago

I would say it’s completely ok to break backwards compatibility every 20 -30 years as is the case with .NET. Breaking compatibility to consolidate and forward past learnings and that kind of thing. The old .NET framework will be supported for many decades into the future, so it’s not necessary to upgrade if there is no benefit, for example when your customers are .NET dev’s who expect to be support with the new versions

formerly_proven 2y ago
This doesn't sound like once every 20-30 years (.NET itself is only 22): > We do not guarantee 100% compatibility between major versions. This is true for both ASP.NET Core and the runtime itself. We intentionally make breaking changes where we believe that they are necessary to move the platform forward and the cost of the .NET ecosystem adjusting to them is low enough. There is a major .NET release every year. Every other release is LTS with 3 years of support. > The old .NET framework will be supported for many decades into the future I'd guess so but Microsoft is not as clear on this as you'd wish. In all their policy documents they say it's "supported as a Windows component on the latest required update" or "Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed." To me this seems to be carefully written to allow the possibility of changing that Windows component status in a Windows release. So, .NET Framework is supported as long as it is part of Windows, until it isn't.
- fabian2k 2y ago
  There was one huge breaking change, that was the move from the Windows-only .NET Framework to the cross-platform .NET Core. I assume that is the one the parent is talking about. The major releases of modern .NET are relatively painless now, there aren't that many breaking changes. This is pretty much the same as many other languages, and kinda unavoidable unless you go for an ecosystem that aims for very long term stability and is essentially frozen. The early .NET Core releases had some annoying breaking changes, but it's very different today.
- Jenk 2y ago
  They are _very_ averse to breaking changes, however.
- dagaci 2y ago
  >>We do not guarantee 100% compatibility between major versions. This is a true caveat for any language or framework, and is a sensible disclaimer. But I think the author was referring to transition from “.Net Framework 4” series (since 2001 when I first used it, ~23 years ago) where Microsoft declared “.Net Framework 4.8” would be the last major version of that series. And that new developments should use the “.NET Core” series, which is now named just “.NET “.
FrustratedMonky 2y ago
I'm curious what a good life time length should be to be considered 'stable'. Allowing your code base to run ok for 10 years, 20, 30 without change. You are talking Cobol type situations where the rest of the industry has moved on, and now your are stuck. So each individual has to judge jumping ship and migrating their systems. Even Python took the leap and did a major revision that broke everything. But guess it had to be done.
- binary132 2y ago
  The Python 3 upgrade nightmare was a big mistake. I’m not saying I know the right way, but just because they did it that way doesn’t mean they had to and should have.
  - baq 2y ago
    It was, but the language as it was in 2 was reaaaaaallly not XXI-century ready. They could ship both interpreters and communicate with RPC for all I care as long as shit still worked. Though to be fair I haven’t written a single line of Python 2 for about 10 years now.
  - bmicraft 2y ago
    It did break everything, but I'd hardly call it a mistake. Python3 is more popular than its predecessor ever was. It was very painful for many people, yes, but it doesn't seem to have hurt the language much if at all.
    - binary132 2y ago
      Just because it worked out doesn’t mean it was fine and the way things should be. There are definitely better ways.

by dagaci 2y ago

formerly_proven 2y ago

This doesn't sound like once every 20-30 years (.NET itself is only 22): > We do not guarantee 100% compatibility between major versions. This is true for both ASP.NET Core and the runtime itself. We intentionally make breaking changes where we believe that they are necessary to move the platform forward and the cost of the .NET ecosystem adjusting to them is low enough. There is a major .NET release every year. Every other release is LTS with 3 years of support. > The old .NET framework will be supported for many decades into the future I'd guess so but Microsoft is not as clear on this as you'd wish. In all their policy documents they say it's "supported as a Windows component on the latest required update" or "Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed." To me this seems to be carefully written to allow the possibility of changing that Windows component status in a Windows release. So, .NET Framework is supported as long as it is part of Windows, until it isn't.

fabian2k 2y ago
There was one huge breaking change, that was the move from the Windows-only .NET Framework to the cross-platform .NET Core. I assume that is the one the parent is talking about. The major releases of modern .NET are relatively painless now, there aren't that many breaking changes. This is pretty much the same as many other languages, and kinda unavoidable unless you go for an ecosystem that aims for very long term stability and is essentially frozen. The early .NET Core releases had some annoying breaking changes, but it's very different today.
Jenk 2y ago
They are _very_ averse to breaking changes, however.
dagaci 2y ago
>>We do not guarantee 100% compatibility between major versions. This is a true caveat for any language or framework, and is a sensible disclaimer. But I think the author was referring to transition from “.Net Framework 4” series (since 2001 when I first used it, ~23 years ago) where Microsoft declared “.Net Framework 4.8” would be the last major version of that series. And that new developments should use the “.NET Core” series, which is now named just “.NET “.

FrustratedMonky 2y ago

I'm curious what a good life time length should be to be considered 'stable'. Allowing your code base to run ok for 10 years, 20, 30 without change. You are talking Cobol type situations where the rest of the industry has moved on, and now your are stuck. So each individual has to judge jumping ship and migrating their systems. Even Python took the leap and did a major revision that broke everything. But guess it had to be done.

binary132 2y ago
The Python 3 upgrade nightmare was a big mistake. I’m not saying I know the right way, but just because they did it that way doesn’t mean they had to and should have.
- baq 2y ago
  It was, but the language as it was in 2 was reaaaaaallly not XXI-century ready. They could ship both interpreters and communicate with RPC for all I care as long as shit still worked. Though to be fair I haven’t written a single line of Python 2 for about 10 years now.
- bmicraft 2y ago
  It did break everything, but I'd hardly call it a mistake. Python3 is more popular than its predecessor ever was. It was very painful for many people, yes, but it doesn't seem to have hurt the language much if at all.
  - binary132 2y ago
    Just because it worked out doesn’t mean it was fine and the way things should be. There are definitely better ways.