AngularJS, Angular and Angular v4

Talk about AngularJS, Angular and Angular v4

  • The old and new Angular products need names that are fixed and independent of the version number.
  • With semantic versioning, you can tell if a new release is an easy install, with no breaking changes, simply by looking at the version number.
  • The downside is that breaking changes are inevitable and, therefore, new releases of Angular are bound to have version numbers like , , , etc.
  • Semantic Versioning (SemVer) is a convention that dictates how the version number changes for each new release of a library.
  • A breaking change means that upgrading to the new version of the library might cause your application to behave in an unexpected way that contradicts previously documented behavior or fail outright.

Angular tips blog

@AngularJSFan: Talk about AngularJS, Angular and Angular v4

A lot is happening in the Angular world. A few years ago Angular split into the “Old World” of Angular v.1.x and the “New World” of Angular v.2. Both worlds carry the “Angular” label, which is almost as confusing today as it was when the split happened.

What’s up with the re-branding of Angular v.2 as “Angular”? What is SemVer? And just as we were getting used to Angular v.1 and Angular v.2, along comes Angular v.4. Is that a third “New World”? What happened to Angular v.3?

Yikes, all of this is really confusing!

This article aims to bring clairity to the confusion. At the end, you’ll understand what’s going on, why, and how these changes affect you.

Two Angular Worlds

There are two “Angulars” … and only two “Angulars”.

Angular v.2 was a decisive break from Angular v.1. It’s a new architecture, a new platform, a completely different product with its own approach to building a web client.

Every Angular version from v.2 forward is a step in the evolution of this new product. There will never again be a completely new product called “Angular”.

It might have been better to give the new product an entirely new name. But the Angular team wanted it to inherit the market position, momentum, and fantastic community of the original Angular. To be fair, the same Google team was building the new platform and there is enough conceptual continuity to justify keeping “Angular” in the name.

We were getting used to the idea of calling the old product “Angular 1” and the new product “Angular 2”. But there is a problem. The new product must evolve. Each new release needs a version number. For valid reasons to be explained, for certain releases, the team wants to be able to change the first digit in the version number.

It’s impossibly confusing to refer to the product as “Angular 2” when its version numbers become v.4, v.5, v.6, etc.

The old and new Angular products need names that are fixed and independent of the version number. So they’ve been re-branded.

is the official name of the “Old World” product, once known as “Angular 1”.

is the official name of the “New World” product, briefly known as “Angular 2”.

No more “Angular 1” or “Angular 2”.

. They aren’t going away overnight, nor should they.

Breaking changes

. It was never obvious if it was safe to update my application to a new release.

version numbering scheme. Any update can break your application (more on breaking changes below). You must read the change log, understand what it says, and hope for the best.

. That seems like a minor update. You install it and, boom, you get unexpected errors in unexpected places.

That is so wrong. Updates should be clear and predictable. We should know at a glance if an update can break our code.

Today’s applications can have hundreds of dependencies. No one can be an expert in every dependency. No one has time to read all of the change-logs. We need a simple way to quickly identify which updates are safe and which could be dangerous.

works later). One day, while processing a pull request to fix a typo, our Travis continuous integration system produced 200~ failing tests.

How can a typo cause 200 failing tests? After one hour, we discovered the problem. A new version of AngularJS had been released a few hours ago. The update contained an unexpected (and undocumented) breaking change related to animation. Here is the proof.

Things like that happened quite a few times. It happens less frequently now because (a) the AngularJS team is better at documenting breaking changes and (b) AngularJS has fewer breaking changes because it isn’t evolving.

It’s still a significant risk for an application with dependencies on other libraries that are more volatile and less carefully documented.

isn’t the only library with this problem. Hundreds of other libraries release updates with breaking changes every day.

Angular and semantic versioning

library escapes this problem by adopting semantic versioning.

), the release contains a breaking change. You have to investigate what has changed and decide when the time is ripe to upgrade.

, etc.

and beyond.

What is semantic versioning and how does it work?

Introducing Semantic Versioning

Semantic Versioning (SemVer) is a convention that dictates how the version number changes for each new release of a library. The version number of a library that conforms to SemVer tells you how each release differs from its predecessor.

A SemVer version has three parts.

We say that a release is a major, minor or patch release when the most significant (left-most) changed number is the major, minor, or patch digit.

Patch release

. Suddenly we discover that there is a bug on the datepicker. We forgot about leap years, so February 2016 didn’t have 29 days.

Sounds like a pretty big issue, so we want to make a fix-it release right now. What kind of change will this be?

. We know beforehand that the release only contains bug fixes so it is safe to update. That is what we call, a predicatable release.

, and so on.

Feature release

When an update only contains fixes, we release a patch version, but when an update contains at least one new feature, it should increment the version’s minor digit, making it a minor release. A minor version can optionally, contains bug fixes as well.

version of the datepicker.

Major release

Updating your app with a patch or a minor version should not break the application. It may fix bugs or introduce new features that you can exploit while updating your app. But the new release shouldn’t cause your app to fail or behave differently than you intended.

datepicker a year from now without making any changes to your app.

Sometimes to fix a bug or add an important feature, we have to make a breaking change. A breaking change means that upgrading to the new version of the library might cause your application to behave in an unexpected way that contradicts previously documented behavior or fail outright.

So… what is exactly a Breaking Change?

property like this:

option that is true by default. The datepicker would flash annoyingly when the date changes.

Among the one million datepicker users only one person like the option option. Man, I should go out for beers with that person because obviously we like the same stuff. Was it a bad idea? Probably, but there it is.

. The list of options, the implementation, and the effort to configure a datepicker is getting way out of hand:

This has to stop. It’s hard for developers to databind to this component because it has so many separate hooks. The code is becoming a mess. Change detection is working overtime. If current trends continue it will only get worse.

object that works like this:

property with the desired custom settings.

That’s a vast improvement for everyone.

Unfortunately, it’s a breaking change. The 99% of users who never set an option because they liked the defaults aren’t affected.

they’ll get an Angular compilation error complaining about unknown properties.

, perhaps like this:

A Breaking Change is a change that forces a user to update an application when upgrading to the new library. It doesn’t matter how few users are affected. It’s a breaking change if it affect anyone.

know, simply by looking at the version number, that this new release might break their apps.

You do have a change log, don’t you?

Identify breaking changes in the change log

SemVer doesn’t require a change log but every library should have one. The conventional change log is a Markdown file called

Your change log should have a new entry for each release, whether patch, minor, or major. The release entry identifies what changed in that release.

could be as simple as:

NPM and SemVer

NPM helps us manage libraries that conform to SemVer. I’ll give you the short story here. You can get the official story on the web

file. We have different ways of specifying the library version. We can install a specific version of a library by supplying the exact version number:

install a patch version equal to or greater than specified but not a higher minor or major version:

install the latest minor and patch versions but not a higher major version:

version format because it allows you to stay current without risk of installing a major version with a breaking change.

with the third.

release that breaks your app — if the library author followed the rules.

which contained a breaking change.

That hurt. It took a long time for me to figure out what was wrong.

which does follow SemVer.

was a bad idea. The new Angular wasn’t the old Angular with some breaking changes. It was complete rewrite of the framework from the ground up. It deserved a new product name, not a new version number.

. The moment we adopted semantic versioning, we knew that the major version number would keep growing.

… forever.

This confusion had to be addressed, first by re-branding and then by separating the product name from the version number.

at the time of this article) and be 100% sure that our application will continue working as it did before.

and so on. But there have been no breaking changes.

, like every other living library, must evolve and evolution entails breaking changes.

There are many sources of breaking change.

Sometimes there’s a much better way to doing something that requires a minimal breaking change that affects a few people. How few doesn’t matter.

Sometimes the only way to fix a critical fix is a breaking change.

Sometimes the cause is Angular’s reliance on an upgraded dependency that itself imposes a breaking change. Angular v.4 is built with TypeScript and you’ll have to upgrade to at least TypeScript v.2.2 to use all of Angular’s capabilities.

You can see other examples of Angular breaking changes in the change log for the Angular v.4 release candidates.

Scheduling breaking changes

The Angular team understands that updating a big application is not a casual or easy task. No one wants breaking changes. But it they must happen, they should be predictable.

Most organizations need to plan and find resources for an upgrade effort. They want to know, in advance, how often Angular will change and, most importantly, when an Angular release will contain breaking changes.

Accordingly, the Angular team decided on a release schedule that allows the product to take small steps forward — patch and feature releases — every few weeks and to take big steps forward — with possible breaking changes — every six months.

The schedule for 2016-2017 looks like this:

Optional upgrade

The schedule helps you plan. Upgrading is always optional. You do not have to upgrade every six months just because Angular does.

What happened to Angular v.3?


. etc. You can install only those modules that you actually need in your app.

app, you see:

You see the problem? All packages have the same version except the router, so if the next Angular release became v3, what should happen?

How different is Angular v.4?

is primarily a maintenance release with a few breaking changes.

The most notable breaking change is that lifecycle hooks are no longer abstract classes. They’re interfaces now. Most applications treated them as interfaces anyway but some app classes inherited from these classes like this:

like this:

That’s not a big deal, is it? You can fix your entire application with a simple search-and-replace in a few minutes..


There are others breaking changes, but they will only affect a minimal number of applications, if any.

Be sure to check the change log before upgrading.


is a worthy upgrade that shouldn’t be too difficult to install.


We hope you can see now that the reality is much more pleasant. Angular is great today and steadily evolving along a predictable path to a productive future. Angular v4 is an incremental step forward.

If you haven’t tried Angular yet, start today. Most of you can update your v2 applications to v4 in an afternoon. You’ll be glad you did.

This article has been written by Jesús Rodríguez and Ward Bell.

AngularJS, Angular and Angular v4

You might also like More from author

Comments are closed, but trackbacks and pingbacks are open.