Semantic Versioning for Angular npm modules
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Introduction
In the world of software management there exists a dreaded place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.
What is versioning?
Consider a version format of X.Y.Z (Major.Minor.Patch). Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version. Above
When to create a new version? What are the steps?
If any addition or amendment is required in the component, a new version is to be introduced.
Step 1) Before check-in, verify which is the latest checked-in version number
Step 2) Add an entry in the confluence page with version number and description regarding bugs fixes / feature added / of the released version
What should be the base version?
Base of all 0.0.1.
Next version should be 1.0.1. Tell me why?
Example:
Case 1) Document-1 is currently using 1.0.1 of a component-A, there is a bug fix required in component-A. Here a new version to be created incrementing the ‘patch’ column of the version number.
So, new version will be 1.0.2.
Case 2) Document-2 is currently using 1.1.0 of same component-A consumed by Document-1.
Additions in component-A require fixes from all the previous versions.
In this case, merge all the previous changes and create a new version 1.2.0.
Why 1.2.0 and why not 1.1.1?
As per the semantic guidelines if we combine multiple patch versions into one, it is recommended to introduce a ‘minor release’ and increment the minor digit resetting the patch digit to 0.
Hence, Base version for introducing new version must be the ‘last version consumed by that respective document’
Can we check-in incomplete or unstable version? What should be the version number for the same?
Yes.
For an unstable or incomplete code, version number should be suffixed with ‘-beta’ like 1.0.0-beta, also update this information in the confluence page for other developers to understand that 1.0.0 is in-progress. This has to be continued in an incremental format.
