Replies: 1 comment
|
Breaking changes are breaking NOT just because it require manpower to handle. It's often not handle-able or manageable at all. The compatibility rule allows compiled code to just work on updated version for most cases, without any process of changes in source code. Not every software is keeping updated. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
With the rise of AI, agentic development, and the growing idea of having "trillions of agents working for me 24/7," I think the .NET team should reconsider its approach to breaking changes.
In the past, breaking changes could be a real burden, keeping developers busy for days while they tracked down and fixed countless small issues across a codebase.
Today, many of those changes are exactly the kind of work that AI agents excel at. They are repetitive, localized, and easy to verify. As these tools become more capable and widely adopted, the cost of dealing with SMALL (that's the key point) breaking changes will continue to decrease.
For that reason, I think the .NET team can afford to be more flexible with breaking changes in future releases, especially when they enable meaningful long-term improvements to the platform.
All reactions