Your first foray into web development and you picked a large, unfinished (it wasn't final) framework to learn with? Then you are complaining that there were breaking changes you had to deal with?
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.
>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.
I don't think the idea of "planned" breaking changes every 6 months to be such a bad thing. A major release twice a year that you can upgrade to when you're good and ready.
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.
This release cycle is fine so long as you don't rely on anything but Angular 2.
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.
This makes the improper assumption that you're forced to upgrade. The code for Angular 2 will not evaporate when Angular 3 appears - at that point the choice to upgrade to the latest version is just that: a choice. You are free to wait until Angular 4 comes out before you adopt Angular 3 if you want to make sure the ecosystem around it is solidified.
I've been 'forced to upgrade' in the past by issues in dependencies that won't be fixed, with other dependencies not updated yet. It's a sticky wicket.
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.
It sounds odd to me that an app would include packages that have dependencies on a framework. I'm having a hard time picturing an example, can you provide one?
I'd like to point out that React has had breaking changes roughly 6 or less months apart also. This is a red herring of an argument, we see lots of successful libraries make breaking changes that often doing fine.
The scope of the breaking changes matter more, and that story has yet to be told.
> I'd like to point out that React has had breaking changes roughly 6 or less months apart
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.
Rails introduces some breaking changes now and then. The only troublesome upgrade was when they added the asset pipeline. Was that 3.0 or 3.2? If Angular is adding some features while deprecating others it won't be a big problem. If they break compatibility in a big way every six months, maybe it's not the place to be. High maintenance costs means that it's hard to sell to customers and even for internal projects one should evaluate if it's wise to allocate resources on rewriting the same code again and again. We'll see.
One other project comes to mind that also updates every six months: Ubuntu. Last I checked, their ecosystem was doing fairly well. I wouldn't consider Ubuntu "unfinished" unless we're talking about the state of all software everywhere.
Does Ubuntu ship breaking changes every six months?
Do Ubuntu developers rely on other developers to keep their shared code updated and/or fork their repositories to support both new and old versions of the framework, every six months?
But, of course, Ubuntu also has LTS (Long Term Support) versions for people who don't want to upgrade frequently (you get security patches and the like but otherwise things stay stable for years).
Ok, now try to find at least one framework without breaking changes after initial release. Code should evolve, planned changes is a graceful evolution.
Breaking changes are to be expected. Breaking changes every six months are how you ruin an ecosystem.
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.
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake. A release candidate is a "release candidate", that is to say "we're pretty sure we could release this whole thing right now, but we want to send it out to the community to make sure there are no catastrophic bugs we haven't noticed". In other words feature-complete, and with most of the kinks ironed out.
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.
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake
Quoted for emphasis.
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.
RCs should IDEALLY not have breaking changes. You can dice it up any way you want, but it wasn't a final build and there were obviously some rough edges.
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.
Not that I find the debate particularly productive, but "there will be no breaking changes" doesn't mean "final", it usually means (at most) release candidate. Or even beta. While "it works but we might still introduce breaking changes" is not a release candidate but maybe a technology preview.
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.
It was the TypeScript team that invited the Angular team to build Angular 2 on top of TS (at the time, they were planning their own JS dialect called AtScript), so I would be surprised if they later changed in a way that seriously broke compatibility with Angular 2.
Unfinished because they essentially announced Angular 2 as the "we got the first so wrong we're throwing away huge chunks". It literally got announced with gravestone images and tolling bells for various features. As web devs we know this.
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.
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?