The real story here is the seemingly casual way they've decided to start treating breaking changes. Deprecation periods are more polite than not having them, but saying that users need to be constantly using the most up to date version to get information about future support, and then introducing breaking changes into the current version more regularly, seems like a step in the wrong direction. Projects who lose a lot of community engagement due to breaking changes should be the ones who understand how much of a self-inflicted hassle that is best.
while I don't disagree with your premise, I think a more generous conclusion is that the angular team has learned from the 1->2 disaster, and has decided to focus on the long term, even if that means causing more headaches in the short term.
But my concern is about how they are scheduling breaking changes to occur so frequently, and almost two years in advance! Why induce that kind of headache over and over so regularly that the short-term issues become a long-term software maintenance burden?
I cannot imagine working on a software project where I'd want to plan out four distinct breaking change updates. I simply cannot prognosticate my needs that well, nor chessmaster so deeply that I wouldn't just do it in one bigger change. If they're anything like me, that means they're committing to inducing the hassle _without even knowing what the payoff is_!
> while I don't disagree with your premise, I think a more generous conclusion is that the angular team has learned from the 1->2 disaster, and has decided to focus on the long term, even if that means causing more headaches in the short term.
Did they really ?. If they did they would focus on API stability instead of breaking changes. Moving to semver is an issue when a product didn't use semver at first place.
I want them to succeed but I also want to be able to pickup a framework I didn't use for a year without having to relearn its API.
They probably should have followed the PHP release pattern, which introduces breaking changes to the language in a more gradual way, over a couple of releases, instead of doing it in one big go.
On the other hand, the assumptions people have about the changes between Python 2 and 3 are probably bigger than they really are. I've started writing new code in P3 the last two years or so, and the only thing that still stumbles me from time to time is the parentheses around the `print` method.
Honestly, the string / unicode fix is the biggest thing that breaks Python 2 scripts in Python 3, and Python 3 is so much better for having made the change. I don't see how that particular change could have been pushed through without breaking everything--and yes, I am counting the miscellaneous fixes they pushed through afterwards like bringing back u''.
They didn't do anything wrong. But users are left with massive Python 2 codebases (certbot/letsencrypt, caldav-server/twisted, blender, maybe some OpenStack stuff and probably much more) that are very useful/essential to their users. What do you expect mere users to do? Invest massively in porting (adding test cases in the process where there don't exist any)? They will rather keep Python 2 around forever.
I wouldn't be surprised if Blender was dragging their feet moving to Python 3 just because all of the major 3d software tools have embedded Pythons that are only recently reaching 2.7 (Maya, Nuke, Houdini, Mari, etc).
One big problem they had was that they felt that hosting multiple Python versions on a system was a sysadmin problem, not a language runtime problem.
This is an issue because many platforms and products shipped with some python2 scripts. So a developer trying to use python3 needed to start by setting up a mixed environment on their own.
Ruby could get away with crap like that because it wasn't widely used outside of Rails before rvm/rbenv was common.
Setting up python3 as the default python could break certain Linux distros.
Even today MacOS ships with python 2.7 as the default.
As someone not familiar with the situation, could you please give a brief of what happened with the Python 2 to 3 transition and why did it turn out so bad?
Python 2 had an inherent flaw with character encoding. While passing data around, strings and bytes were treated as the same thing, until they weren't the same thing, at which point your software broke in horrible and unexpected ways.
Python 3 fixed it, along with some other less drastic changes. Despite a gradual and ever ongoing migration to python 3 by every major library (http://py3readiness.org/https://python3wos.appspot.com/), a lot of HN posters love to talk about how they'll never use python 3.
The secret is: no one cares. People still use java 1.4.2 and that hasn't impeded Java.
Python 3 was a large and backwards capability breaking change that required people to learn some minor new behaviors when writing code, but it has been and will continue to be the future.
How is using semver casual? In AngularJS they introduced breaking changes a number of times, without a major version bump. Using semver makes it really clear, and since they are being so strict about it, there is greater confidence when updating to non-major releases. I think this is great.
Their 6 month release cycle is also very smart and allows for planning. I know that I'm only ever going to need to fix things once every 6 months when updating the library (if I do choose to update it) which seems pretty good to me.
