I get your beef with the ecosystem, but this is a very unfair knock on Angular 2. Angular 2 was not the problem here at all.
Am I missing something obvious?
>Angular 2 is going to have breaking changes only every 6 months from now on. So the next one would be around February with Angular 3. Yes exactly, they’re also finally switching to semantic versioning which is a huge win in my opinion.
IMHO, breaking changes every six months is the recipe for an shitshow of an ecosystem.
Sounds like a way to prevent having to completely rewrite from the ground-up to keep up with the web a la angularjs.
I like React because it's a lot smaller but I totally see the advantages of Angular 2 and I kinda dig the major release cycle.
As soon as you rely on packages that support Angular 2, the 'good and ready' argument breaks, since you can't start till all the packages you rely upon have already made the upgrade, and you can't take to long either, because you can't expect further work or fixes to be made to older versions of the packages.
12-month breaking changes, that would have made sense.
That said, breaking changes every six months seems to be commonplace in major open source packages. My initial reaction was 'OMG, now they want to repeat the Angular 2 debacle every 6 months?!?', which doesn't seem to be the case.
http://tech.shantanugoel.com/2008/05/21/ubuntu-what-exactly-...
The scope of the breaking changes matter more, and that story has yet to be told.
The more I reflect, the more I see this as about poor expectation management and messaging from the Angular team than an actual story.
When? Can you cite an example? Keep in mind that for most breaking changes React typically goes to a deprecation warning for the duration of a major release instead of hard-breaking changes, so in reality you have roughly double the time between truly breaking releases, generally speaking.
That is true about the deprecation, although some of the earmarked breaking changes have been quite painful too.
Hopefully the Angular team takes this route for planned breaking changes & apply engineering to ease compatibility.
React releases every 6 months or so, and puts deprecation warning on anything that is breaking in the next update, so you have a full year between any breaking features, and six months for everyone to update before they land.
It's sheer insanity to make breaking changes or upgrade the dependencies between a release candidate and a final version. The upgrade from a release candidate to a final version should be the easiest upgrade in the world.
Angular 2 is final now and they've committed to no more breaking changes until the next major build (at least 6 months away). If s/he started learning with it today, then ~90% of what s/he was complaining about in this post wouldn't have been a thing. That was my only point.
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake
Release Candidate means "The API is considered finished and we are stabilizing the code before our final release"
Release Candidate doesn't mean "Beware! Don't you dare to build a real world application with our library since we will be breaking the API on a whim".
If I wanted a dependency to have unpredictable breaking changes every minor version I would pick an Alpha version, not a Release Candidate one.
Although to be fair, in my particular case it was my fault, seeing "Breaking Changes" in the changelog of a Release Candidate was a red flag I decided to ignore.
I also recall there being around 30 issues for Angular 2 Final on github milestones the day they announced the release, but they were mysteriously gone in the afternoon.
Angular 2 Final seems to be anything but.
For someone coming from the Java world seeing a very popular framework with a release candidate of their 2.0 release - that would portray a very different story.