Most cases this will probably be fine, and things like spring etc. will move on. I was a bit surprised the latest 'hippo' was still java 8, https://documentation.bloomreach.com/library/about/system-requirements.html but they depend on an open source stack with some parts have little users then there own. So they should either invest time making those java 11 compliant, or switch them for other ones who already do. Another problem they might have is have a lot of cross module dependencies making it hard to properly support modules.

I don’t think there is a way to do this right. Breaking compatibility was a bad plan, but not breaking also. To me it feels like it was picking the lesser of the two evils.

Sad thing that there are no alternative timelines. I wonder where Python would be if they didn’t break compatibility.

The funny thing is that to my understanding, there could be some interoperability between 2/3, if that was an explicit goal. But the rationale was also that the Python interpreter was getting bloated and adding support for both flavors would be too much of a burden. Then a lot of semi-religious arguments broke out and here we are now...

Regardless which camp is right (or most right, for some definition of right), and however much better the new version became, it's not much fun to be in the middle of a low-key war as a language user. Rich's recommendation springs to mind here: maybe they should have changed the name of the language.

At this point, they almost did.

(Change the name: because people explicitly mention the version number.)

They surely should have done it with Angular(js). Especially non tech people now think it's almost the same thing.

I’m not aware of a language that has manoeuvred this successfully, but there certainly are other dramatic version changers (Perl 5 vs ...6?, PHP 5.6 vs 7.*)

It’s a branding decision; personally I’m a fan of new names (not changing the name makes it easier for devs to sell the business on an upgrade though...)

How big is the difference for Angular?

I think the name-change opinion comes precisely from observing these kinds of developments, where the version number becomes fused with the name and stops being an independent semantic unit. Like you say, maybe the effect is the same in the end, but perhaps there would be a difference in terms of turmoil and confusion. Of course, it also means that the new language would have a lot more marketing to do, which perhaps comes for free if you get everyone riled up. If you fork and then mutate the language to the point of incompatibility, yet retain the name, maybe you can at least get 50% of the previous community (and a war).

I know it makes it easier to sell the upgrade, but that's mostly the reason I don't like it. It's hard to make the case that instead of moving from AngularJs to Angular (as an 'upgrade'), we might better move to react.

I guess it’s also a discussion of sentiment, to the ones making Python 3 is is ‘just Python with all mistakes fixed’

Again, not to say what is right or wrong

Well, you could call Rust "C++ with all mistakes fixed". To disagree, we'd have to have a discussion of nuances and degrees to differentiate why Rust warrants a different name but Angular and Python do not. Or you take the hardline stance that if it's fundamentally incompatible, it's a different language/framework. Lot's of languages and frameworks resemble one another closely, on purpose (since familiarity is a huge selling point for those to whom programming is strictly a job and not a passion), yet do not share names.

Yeah right, it is always easier to say that ‘incompatibility’ means ‘different’ than to try to negotiate where the line is between ‘different but same’ and ‘different’.

That said, it is perfectly possible to write Python that runs on both 2 and 3 and there are very deliberate attempts at making this transition easier. So if I were to compare that to the Rust/C++ example I would place it closer to ‘different but same’. But that certainly ends in a discussion of nuance which I don’t intend to invoke.

For isolated deps there is virtualenv

(Not saying that is perfect, but there is some form of solution there)

Virtualenv has always been a strong standard when I have worked with python. requirements.txt is disappointing due to the inability to remove transitives.

pipenv is a good solution. It's kind of yarn for python (lockfile, cache downloaded deps...). It's a good solution, but it's not widely used (and it took me a few weeks to find this solution)

Yeah, that is the same issue I have with pipenv, the hustle that I have to go through building a docker image or something along those line with just pipenv really annoyed me.

I think it's newer