Learn about the Uniform Semantic Versioning (SEMVER) for Angular

The Angular version 4.0.0 is out in the market immediately after Angular 2 which was released in September 2016. You may be noticing three numbers i.e. 4.0.0, this is nothing but the angular release version which going forward will use Uniform Semantic Versioning which is also known as SEMVER. In this article, we are going to discuss the SEMVER concept and why suddenly the recent angular release switched to SEMVER and evaluated its new version as 4.0.0 immediately after Angular 2.

SEMVER
SEMVER stands for Uniform Semantic Versioning. It has a version number defined as MAJOR.MINOR.PATCH which gets incremented regularly by the following rule of thumb.

• MAJOR version is bumped up to the next number when we make incompatible API changes.
• MINOR version is bumped up the next number when we introduces a new functionality which is backwards-compatible.
• PATCH version is bumped up to the next number when we make bug fixes which are backwards-compatible.

Also, we can introduce additional labels for pre-release and build the metadata as extensions to the actual MAJOR.MINOR.PATCH format after obeying the specifications.

Why use SEMVER?
As the application grows in its coverage and functionality, the development team adds more files into the application packages and it becomes quite difficult for the project management team to keep track of the software releases. It becomes very difficult to keep track which release had the new and deprecated functionalities? Was that release a major, minor or patch release? To overcome such confusions and in order to keep a smooth track of software release version for the new or deprecated functionalities, SERVER provided the best solution as a version format of X.Y.Z (Major.Minor.Patch) that made the life easy of the project management.

When a current version is compared against the previous version of a software application. Say the old version of software was 3.1.2 and its new version is 3.1.3. By simply comparing these two version, one can easily understand that the latest software release was for bug fixes or a software patch release.

Semantic Versioning Specification (SEMVER)
The following are the Semantic Versioning Specification.

• A Software organization that uses Semantic Versioning must declare a public API. Such API should have concrete documentation, which is precise and comprehensive.
• A regular SEMVER version number must has the X.Y.Z format, where X, Y, and Z are non-negative integers. There must not be leading zeroes in the version format. Each of these integers will be incremented numerically depending on the nature of the release as major, minor or patch release. E.g. 3.1.2 -> 3.1.3 -> 3.2.0.
• After, the release of a versioned package, the software package contents of the latest version must not be modified. In case, if there are modifications the new software package must be released as a new version.
• Initial development has the major version as zero (0.Y.Z). During successive new release, the actual public API may change anytime. Therefore, the API should not be considered stable.
• The public API has the Version as 1.0.0. This version number is incremented after this release will depend on the current public API changes as major, minor or bug fixes.
• A patch version has an equation as Z (X.Y.Z | X> 0). It must be incremented only when a software organization introduces any backwards compatible bug fixes to the public API.
• A minor version has an equation as Y (X.Y.X | x > 0). It must always be incremented only when a software organization introduces any backwards compatible functionality to the public API. If required, it may also include patch level changes. Always, a patch version must be reset to 0 whenever we increment a minor version (e.g. 3.1.3  3.2.0.).
• A major version has an equation as X (X.Y.Z | X > 0). It must be incremented only when a software organization introduces any backwards incompatible changes to the public API. If required, then it may also include minor and patch level changes. When a major version number is incremented then patch and minor version numbers must be reset to 0 (e.g. 3.1.3  4.0.0).
• A pre-release version may be represented by adding a hyphen and a series of dot separated identifiers immediately after the patch version. The identifiers must always comprise only of ASCII alphanumeric and hyphen [0-9A-Za-z-]. The identifiers must not be empty and numeric identifiers must not include leading zeroes (e.g. 4.0.0-alpha, 4.0.0-alpha.1, 3.0.0-0.3.7, 4.0.0-x.7.z.92, etc.).
• Build metadata may be represented by adding a plus sign and a series of dot separated identifiers immediately after the patch or pre-release version. The identifiers must comprise only of ASCII alphanumeric and hyphen [0-9A-Za-z-]. The identifiers must not be empty and the Build metadata should be ignored when the software organization determines the version precedence. Therefore, the two versions which differ in the build metadata only will have the same precedence (e.g. 4.0.0-alpha+001, 4.0.0+20130313144700, 4.0.0-beta+exp.sha.5114f85, etc.).
• Precedence denotes the versions comparison to each other when they are ordered. Precedence must be evaluated by separating the out the version into major, minor, patch and pre-release identifiers in this order (e.g. 4.0.0-alpha < 4.0.0-alpha.1 < 4.0.0-alpha.beta < 4.0.0-beta < 4.0.0-beta.2 < 4.0.0-beta.11 < 4.0.0-rc.1 < 4.0.0).

Angular uses SEMVER (Semantic Versioning)
Angular v2 was released in September 2016 and at the same time the angular team announced that they are going to switch to SEMVER i.e. Semantic Versioning. In Semantic versioning, the type of release is classified into major, minor, or patch release and based on the nature of the software release, the software version will get bumped up accordingly. A semantic version consists of the following three numbers which has the meaning attached to them.

• Major Release: When we release a breaking change then we will increase the first number for the Semantic versioning. E.g. Angular 2 is the complete re-write version of Angular 1. Therefore, it got the first number changed from 1 to 2.
• Minor Release: When we add a new feature to the existing software, then we increase the second number for the Semantic versioning.
• Patch Release: When we fix a bug or defect and release the software, then we will increase the last number for the Semantic versioning.

Why Angular v3 is missed?
GitHub repository at ‘github.com/angular/angular’ has the core Angular libraries which are version in the same manner as 2.3.0, but they are distributed as different NPM packages as shown below. The ‘router’ package module has the different version than the ‘core’ package modules. Due to this misalignment of the ‘router’ package module version, the angular team decided to jump to the Angular v4. Therefore, the core package along with the router package will altogether have the uniform version as Angular 4.0.0.

Conclusion: –
In this article, we discussed about SEMVER, its specification and why angular used SEMVER and switched to 4.0.0 from Angular 2 directly.