Yep, with Spring Boot development is so easy, and even decade old projects are mostly easy to upgrade. I don't have experience from C# or .NET development, but at least compared to Python and especially JS ecosystems it's so much better.
The Core (smaller, but also properly crossplatform) project begun in 2014, fairly major rewrites with breaking changes in the new releases up until 2019 (.NET Core 3.1) and 2020 (the 5.0 release that became the official major "unification" with most parts of Framework having newer alternatives and being "complete" even if 6.0 and 7.0 patched holes).
Projects started with core 3.0/3.1 in 2019 have a pretty easy and clear upgrade path without major breaking changes up until today.
It's not JS/Node volatility, and the cleanups in the language/runtime were well worth it in hindsight (still maintaining old 4.8 applications running under IIS), also 4.8 is still nominally supported so there's no immediate stress in upgrading (There are better semantics today, but with huge projects those semantic differences, mainly no lazy-loading by default are a risk).
That's a pretty low bar to beat.
I had a sheaf of notes about the problem and figured out the math to build a proper dependency resolver for Python and tested out a lot of ideas such as being able to use http range requests to get the metadata out of wheels on PyPi without having to download the whole wheel.
The problem I had no solution for though was "how to stop developers from trashing the environment that the dependency manager runs in." The data scientists I worked with had an astonishing target for wrecking anything at all. Myself I would have my poetry's environment got bad for reasons I didn't understand every few months ago.
I also found the Python community just didn't care that pip didn't really work right. The most seductive form of blub is "I can accept using things that fail intermittently." I got a job coding Java and Javascript and never built the package manager.
Then uv came along and managed to sell itself as "crazy fast" which did connect with people more than "correct". Written in rust, uv would have beaten my system in the fast department, and since it is a binary, there is no way anyone can screw up a Python it depends on -- as I see it, both technical and marketing genius!
I used conda back in that period, it had a correct solver, and it was easy to manage my own packages, but it was slow in the technical sense of "it takes forever to build an environment" and slow in the business sense in that you got something curated which was not always the greatest or the latest but would, back in the day, "just work." Actually you could vendorize any software you need and have your own conda wheels, like I made wheels with different versions of CUDA drivers which are just DLLs so you could be running models with two versions of tensorflow that required two different versions of CUDA and never have to touch the NVIDIA installer.
But today it is a more "just works" experience to use PyPi instead of conda so I don't use conda.
Poetry was a big improvement over pip but I don't believe the resolver was 100% correct (like from looking at the source code) and performance was not that good, not so much because it was written in Python but because it did not have a proper cache, did not exploit concurrency. The Python way would be to use a world class SMT solver for the CPU intensive bit but when the bits hit the bus Rust is better at exploiting concurrency.
So I am happy to have uv.