It's just Angular – introducing semantic versioning
Using semantic versioning is about managing expectations. It's about managing how the user of your application, or library, reacts when a change happens to it. Changes happen for various reasons, either to fix something broken in the code or to add/alter/remove a feature. Authors of frameworks or libraries use a way to convey what impact a particular change has by incrementing the version number of the software in different ways.
A piece of production-ready software traditionally has version 1.0, or 1.0.0 if you want to be more specific.
There are three different levels of change that can happen when updating your software. Either you patch it and effectively correct something, make a minor change that essentially means you add functionality, or make a major change that might completely change how your software works. Let's look at these changes in more detail in the following sections.
Patch change
A patch change means that we increment the rightmost digit by one. Changing software from 1.0.0 to 1.0.1 is a small change, and usually implies a bug fix. As a user of that software, you don't really have to worry; if anything, you should be happy that something is suddenly working better. The point is that you can safely start using 1.0.1.
Minor change
A minor change means that the software version increases from 1.0.0 to 1.1.0. We deal with more severe changes as we increase the middle digit by one. This number should increase when new functionality is added to the software, and it should still be backward compatible with the 1.0.0 version. In this case, it should be safe to start using the 1.1.0 version of the software.
Major change
With a major change, the version number increases from 1.0.0 to 2.0.0. Things might have changed so much that constructs have been renamed or removed. It might not be compatible with earlier versions. Please note that many software authors still ensure that there is decent backward compatibility, but the main point here is that there is no warranty, no contract guaranteeing that it will still work.
What about Angular?
Most people knew the first version of Angular as Angular 1; it later became known as AngularJS, but many still refer to it as Angular 1. It did not use semantic versioning.
Then Angular 2 came along, and in 2016 it reached production readiness. Angular decided to adopt semantic versioning, and this caused a bit of confusion in the developer community, especially when it announced that there would be an Angular 4 and 5 and so on. The Angular team, as well as the network of their Google Developer Experts, started to explain that we should call the latest version of the framework Angular—just Angular. You can argue the wisdom of that decision. Still, the fact remains that the new Angular uses semantic versioning, which means that Angular is the same platform as Angular 2, as well as Angular 10, and so on. Adopting semantic versioning means that you, as a user of the framework, can rely on things working the same way until Angular decides to increase the major version. Even then, it's up to you whether you want to remain on the latest major version or upgrade your existing apps.
