> On Nov 2, 2026, at 3:32 PM, John Huss <[email protected]> wrote: > > I will say that upgrading to this release requires a LOT of effort. There > are SO many breaking changes. I get that this is a major version update, > and I am totally thrilled with the performance improvements. But golly, > this is a huge effort. It is very fortunate that we have LLMs now to help > with the transition, but this is still a rough process. I hope the amount > of breaking changes is going to slow down.
Hi John, Thanks for sharing your experience. This is important, as soon others will start upgrading. Before I go on a rant, a question :) Can you describe your upgrade experience? What you needed to change and what was the hardest to deal with? What else can we add to UPGRADE.md to make things easier? Now my thoughts on the rate of change... Years ago we've noticed how adding even a smallest new feature is insanely hard due to how many edge cases needed to be handled. This is why we still don't have horizontal inheritance. The amount of tech debt that accumulated over two decades is staggering. So the product stagnated and got confusing. Just some examples: 1. Depending on how you count, there are between 15 and 23 Query subclasses in 4.2! How do you explain this to users? And how do you support all of those runtime paths? 2. User-facing APIs from different moments in history (DataContext has older methods that are not in ObjectContext; query methods are different between fluent queries and the context) 3. Three different event models (callbacks, snapshot events, filters) 4. Four independent cache subsystems LLMs presented a unique chance to finally get unstuck, drive towards a consistent mental model that can be communicated to users and meaningfully improve the product. But it did (does) require what essentially amounts to an ongoing open-heart surgery that we never dared to do before. I understand that 90% of our users have extensive existing code bases, so we are creating extra pain. While the core behavior is unchanged (I am trying to keep all the faulting contracts and such) and the model upgrade is done automatically, there are dozens of API changes across the board. More so if people built extensions based on (formally public, but outside ObjectContext / Query) APIs. Those things will be broken and will need to be redesigned as they cannot be preserved in a meaningful way. So I am constantly asking myself if we got carried away too much and when we should stop. From what I see now, at least 6.0 is going to be another breaking release (BTW it is down to just 4 essential Queries already :)). Hopefully we deal with all mapping and Query restructuring there and later work on things like caches quietly without user disruption. Andrus
