Angular 2.0 strikes me as a Maven 2.x moment. Maven 1.x was a brilliant idea that pragmatically addressed real, practical problems with building Java codebases. Some pragmatic decisions turned to be real ugly (Jelly), but you really could get a fair amount of stuff done and have a consistent build process. Then Maven 2.x came out and made everything way more complicated, way more rigid in a way that clashed with real development needs. Weird decisions in Maven 2/3, such as throwing away its dependency on Ant and rewriting all that functionality in a new library (years later, still missing features, e.g. ability to include/exclude files while creating certain types of archives). Such as nearly erasing the differential between internal and external projects, as a result taking away the ability to version all your internal artifacts with one variable. There was also heavy migration pain and overhead, as little of the previous custom code was compatible. And pretty much for all of Maven 2.x/3.x, having used Maven 1.x in serious anger, I was left wondering "why oh why did you do this, and why did you change this?" And many of the public motivations for changes were "academically" right, yet practically disastrous in large projects.<p>So, here we are, starting with Angular 1.x, which seemed to be fairly pragmatically designed to solve certain pains and has received (IMO well-deserved) uptake in the ecosystem. Now, we are looking at Angular 2.x, where many of the decisions seem "academically" right, yet feel to me (and many of us) as practically disastrous.<p>This article is essentially saying: 'some kind of a migration path will definitely be worked on once we have a destination Angular 2.0, so stop freaking out.' Also this statement: ". If you are working on Angular 1.x today and you like it, you should want 2.0 to exist and you should be an active participant in making it happen."<p>Listen, we've been around the block and we've seen projects go through changes like these. And we've seen enough projects fail after changes like these, and we've seen enough 1.x branches wither in abandonment. And we've spent years now advocating for more incremental development approaches that validate decisions little by little. And so when Angular, as a project, decides to make huge changes, Angular tech leadership should understand this modern climate, and should make sure that the messaging touches on migration right away.<p>Look, I'd love to be pleasantly surprised, but I sure am skeptical that this will be a successful transition. It just doesn't sound like the Angular 2.0 project plans are grounded in reality of shipping production code and solving production problems. And I really think that's the root cause red flag that has everyone up in arms.