Angular and SemVer

AngularJS was rewritten from scratch and replaced with its successor, Angular 2. A lot of us were bothered by this big step, which didn't allow us to have a smooth transition between these two versions of the framework. Right after Angular 2 was stable, Google announced that they wanted to follow the so called Semantic Versioning Specification (also known as SemVer).

SemVer defines the version of a given software project as the triple X.Y.Z, where Z is called patch version, Y is called minor version, and X is called major version. A change in the patch version means that there are no intended breaking changes impacting the public API surface between two versions of the same project, but only bug fixes. The minor version of a project will be incremented when new functionality is introduced, and there are no breaking changes. Finally, the major version will be increased when incompatible changes are introduced in the API.

This means that between versions 2.3.1 and 2.10.4, there are no introduced breaking changes, but only a few added features and bug fixes. However, if we have version 2.10.4 and we want to change any of the already existing public APIs in a backward-incompatible manner (for instance, changing the order of the parameters that a method accepts), we need to increment the major version and reset the patch and minor versions; so we will get version 3.0.0.

The Angular team also follows a strict, predictable schedule. According to it, a new patch version needs to be introduced every week; there should be three monthly minor releases after each major release, and finally, one major release every 6 months. This means that by the end of 2018, there will be Angular 7. However, this doesn't mean that every 6 months we'll have to go through the same migration path like we did between AngularJS and Angular 2. Not every major release will introduce breaking changes that are going to impact our projects. For instance, support for a newer version of TypeScript or change of the last optional argument of a method will be considered as a breaking change. We can think of these breaking changes in a way similar to what happened between AngularJS 1.2 and AngularJS 1.3.

Since the content that you'll read in this book will be mostly relevant across different Angular versions, we'll refer to the framework as only Angular. If somewhere we explicitly mention a version, this doesn't mean that the given paragraph will not be valid for Angular 4 or Angular 5; it most likely will. If a given API is available in only a specific Angular version, this will be clearly noted. In case you're interested to know what the changes are between different versions of the framework, you can take a look at the change log at https://github.com/angular/angular/blob/master/CHANGELOG.md.

Now that we've introduced Angular's semantic versioning and conventions for referring to the different versions of the framework, we can officially start our journey!