Don’t be afraid and just `ng update`!

Appreciating the benefits of frequent Angular releases.

We live in an amazing time in which open-source software has become the norm instead of the exception. Every person with a computer and an internet connection has access to tools that are used (and generally provided) by giant corporations for free!

Angular is a great example of such an open source project. It is maintained by Angular Team at Google and made available under the very permissive MIT license, meaning you can use it for free in any of your projects.

As Google aims to stay at the forefront of web technologies, it makes a lot of sense for them to invest in their own platform so they can better dictate how they think apps should be built. The Angular team actively works together with contributors from the community to continuously improve the project.

Visualization of the Angular release cycle.

Angular Versions

Angular is the successor to AngularJS (a.k.a Angular 1.x) and is a complete rewrite. It was announced at ng-Europe in October 2014 and released as Angular 2.0 almost 2 years later, in September 2016.

The Angular Team announced that as of version 2, Angular would fully adopt Semantic Versioning and that they decided to use a time-based release cycle with a new major release twice a year.

Later that year, in December 2016, they announced version 4 (skipping version 3) and with regards to the name they said: It’s just Angular — omit the version number when referring to Angular (the platform) and only use the version number to specify a specific release.

For some people the frequent updates have been a reason to stop using Angular.

YAAR: Yet Another Angular Release?

The Angular Team has been clear in their intentions regarding updates and has succeeded to commit to these intentions. Yet, to some people it’s not clear why the new releases succeed each other so rapidly. To help these people get a better understanding of the benefits of Angular’s approach, here are a few reasons why I think it’s a great thing to have a predictable release schedule.

Developer/business expectation

Developers and businesses can plan upfront when they should spend time to updating their Angular apps. For maintainers of third-party libraries, it’s good to know when the new version comes out, and they can test with the beta’s and release candidates.

Angular can make bigger changes

Breaking changes are never made on purpose, however sometimes it’s inevitable. The major release is the only moment the Angular team can make these breaking changes as per Semantic Versioning.

Deprecation cycle

Any deprecations will be communicated and will include a recommended update path. In addition to that, the old API’s will always at least keep working until the next major version, giving developers a clear expectation on when they must update.

LTS All The Things

In January 2018, the Angular Team announced that ALL the releases will be getting Long Term Support for 18 months after the release. Getting LTS means that any issues related to security or browser incompatibility will be fixed during that period.

It’s just a number

Just because the version number increases with 1 twice a year does not mean that there are always a lot of breaking changes. The upgrades are actually quite gradually.

Releases tend to focus on several area’s. For example, Angular version 6 was a release that introduced a lot of changes in the toolchain, adding features like `ng update`, `ng add` and support for creating libraries in your Angular projects. In that version, the core of Angular did not see any major changes.

Tested by Google

Google uses Angular to build more than 600 of their own internal and public applications, and they all use the latest version. This means the Angular team has a big stake in keeping the update process as fluent as possible. Or, as Brad Green states, they are ‘committed to pain-free updates’.

Source: keynote Brad Green at AngularMix 2018

Dealing with updates

Now that you understand Angular’s approach a little bit better, I will give you a few tips to cope with these frequent updates

Update shortly after the release

Probably the most common (and very sensible) way to handle Angular updates is to wait a few weeks after the major release.

This gives you the time to check if the release works as expected for others, and by that time most known issues will be fixed. It also gives library authors some time to make their packages compatible with the latest version. If you don’t depend on any of the new features, and you want to take some time to plan your update, this is a great way to go.

A very safe way to plan the update is once a new minor version is released. This means you don’t update from v6 to v7 instantly, but instead wait for the release of version v7.1 to update. This way, you will always have a stable and tested release, and any big issues will surely be ironed out.

Don’t update

Here, I’ll say it: ‘You don’t have to update’.

As explained earlier, all Angular releases are supported for 18 months. This means you can safely postpone your update to a later time. You will miss out on the latest and greatest, but you can rest assured that any issues regarding security and browser incompatibility in Angular will be fixed. You might run into issues with third-party libraries that break, but these can be fixed by pinning the versions or using a lock-file provided by the package manager.

Test with pre-releases

Warning: this one is for the daredevils 😈!

While this option is not always viable for all developers and projects, using pre-releases is a great way to keep your project up to date.

The great thing is that you can report any issues to the Angular project or third party library authors. You might even get the change to fix some of the issues you find, and submit some PR’s –a great way to actively get involved with open source projects, which in turn is great for your experience and career — but I digress…

A word of advice!

How to upgrade

This article wouldn’t be complete without information on how to properly upgrade your Angular project. These are the steps I would suggest for doing an upgrade.

Start from a clean commit of a working version. Create a new git branch for the upgrade. Run ng update. Run, test and build your app. Fix any issues, update deprecations, run the previous step again. Commit and merge the changes in to the main branch.

Most of these steps are exactly the ones I would take to upgrade any other application. Only point 3 is really specific to Angular, which is the recommended and officially supported way to update your project since version 6 (and it’s awesome!).

When running ng update, the Angular CLI checks for updates for the Angular dependencies of your app, downloads and installs them and applies changes to the project (if needed for the new version).

After this, your application is updated and you can start testing to see if it still works. You might get deprecation warnings (features that will be removed in the next major release) and this is probably the best moment to fix those.

When the app works in development mode, you can run the tests and try to make a production build. If all went well, you can commit your work and create a PR so that it can be reviewed and eventually merged.

If the update does not work

A valid reason for fear is if the update does not work Since every app is different, there is not a simple path to follow to fix this issue. However, here are some things you can always do:

Read the changelog and the release notes in the blogpost announcing the new release to see if there are any breaking changes that should be fixed manually.

Analyse any error messages, and search for people with the same error on Google, GitHub or StackOverflow. Zero results for your error? Try shortening the message you are searching for by leaving out names of files, classes, variables, etc.

Check for updates of third-party packages. There might be new versions with fixes for the issues you’re facing. There are great tools that can help you update your dependencies like npm-check-updates and npm-check.

Analyse the part of the app that breaks it by exclusion. First, try to get a minimal Angular app running (only an AppModule that bootstraps the AppComponent) and add features back one by one until it breaks. This is a very basic but proven and trusted way to debug an app that does not work for unclear reasons.

Open an issue or ask on StackOverflow if you can’t get any further. Try to describe the problem as best as you can, include version numbers and any errors you get. And very important: keep a positive attitude — it’s always nicer to help a person who’s not complaining. Always remember that the person on the other side is just a human being like you. :)

Keep your apps updatable

If you keep your application up to date with the latest versions, it’s always easier to update to future versions.

What really helps is to stick to best practices that are used in the community, like the Angular Style guide. Heavy customisation often makes updating the app more difficult. Try to stay away from tweaking the build configuration, for example.

Having clean abstractions are also a big advantage. A good practice is to wrap services around (third party) libraries. If an update changes the library’s API, you only have to apply changes at one place, and not throughout your app.

Thanks for reading!

I hope this article has given you some insights on why a predictable update cycle can be a very desired feature for projects and developers.

Of course, I don’t expect you to agree with all the above, and I invite you to let me know what you think in the comments below or on Twitter.

Special thanks to Stephen Fluin for reviewing and fact-checking this post, and my brother Stephan for polishing the text!