Definition: How to Update Versions (Idea) #5
Description
Idea
DECOM.MAINTAIN.RELEASE
The labels should be a number starting from 0.
The label should be incremented by 1, based on the type of changes.
When changes are made - of different types - each associated label should be incremented.
Example:
Releaser's Perspective:
| Type of change | Version increment |
|---|---|
| New feature was added | 1.0.0 -> 1.0.1 |
| Existing feature was modified | 1.0.1 -> 1.1.1 |
| Existing feature was removed | 1.1.1 -> 2.1.1 |
| Deprecating old feature, and adding a new optional replacement | 2.1.1 -> 2.2.2 |
| A release including a breaking add-and-replace change | 2.2.2 -> 3.2.3 |
User's Perspective
| Version Increment | Meaning for the User | Requires User Attention? |
|---|---|---|
1.0.0 -> 1.0.1 |
New feature(s) were added | Should not |
1.0.1 -> 1.1.1 |
Existing feature(s) were modified | May |
1.1.1 -> 2.1.1 |
Existing feature(s) were removed | Should |
2.1.1 -> 2.2.2 |
Existing feature(s) were modified (deprecated?), and new feature(s) were added | May |
2.2.2 -> 3.2.3 |
Existing feature(s) were removed, and new feature(s) were added (replacements?) | Should |
3.2.3 -> 3.2.10 |
7 RELEASE versions, new features were added |
Should not |
3.2.10 -> 3.10.10 |
8 MAINTAIN versions, existing features were modified |
May |
3.10.10 -> 10.10.10 |
7 DECOM versions, features were removed |
Should |
Note
Please note, "8 new features" would in reality mean 8 RELEASE versions, this could be any number of actual features, functionality or behaviour. The idea is NOT to increment each label by more than 1 for every version. However, the version number should, at a glance, give a rough idea of how many versions have been since, and of which types.
This "solves" the issue with Semantic Versioning, which resets numbers back to 0. This loses a lot of information for the user. Another problem with Semantic Versioning, is that a lot of changes goes into a MAJOR release. It is basically a dump of changes.