13
Which versioning should be use for my project? - Versioning system comparison
Depending of the kind of project you are working on or if it's your first project, you may ask you which versioning system you want to use.
And the answer is simple
What ever you want!
Yes, for sure! You can do what ever you want! You can establish your standard.
But is it great to be understandable by everyone? May be not. (It will depend the context)
So here are some versioning standard which are ready to use, or ready to use as basis to create your standard.
The 3 digits versioning is the most common version presentation that we will found on IT projects. But here I will talk about a particular one which I saw on multiple projects in my career. (So there may be is a standard somewhere, but I haven't found it.)
The version contains 3 numbers :
MAJOR . MINOR . BUG
- MAJOR : Change when you add a new big feature or a new feature related to any existing feature
- MINOR : Change when you add a little feature on an existing feature or do an update
- BUG : When you correct a bug
For a frontend project, it can be ok. For a backend project... it will be confusing.
example
- 0.1.0 -> Start first feature
- 0.2.0 -> Code update
- ...
- 0.5.1 -> Correct a bug
- ...
- 1.0.0 -> Release of the first feature
- 1.1.0 -> Code update
- 1.1.1 -> Correct a bug
- ...
- 2.0.0 -> Release of a new big featureIf you want to have a clear versioning for your backend project, use the Semantic Versioning.
Also based on a 3 digits versioning, it will be easier for your and your consumer to know what's happening in a quick look.
MAJOR.MINOR.BUGFIX
Here, the MAJOR stay at 0 until you go in prod. Then you update it when you have a breaking change in your API.
The MINOR will change for every changed until you go in prod. Then, it will change everytime you do a change which is not a breaking change and not a bugfix.
The BUGFIX will change every time you have to do a correction in prod.
So clearly, when your customer will see a new version, they will know if they have to do an update or not.
example
- 0.1.0 -> Start of your project
- ...
- 0.14.0 -> Code update
- 0.15.0 -> Bug correction
- ...
- 1.0.0 -> First release in prod
- 1.0.1 -> Bug correction
- 1.1.0 -> New feature
- 1.2.0 -> Update without breaking change
- ...
- 2.0.0 -> Update with a breaking changeAnother kind of versioning is with 4 digits. Here is an example about it
MAJOR . MINOR . REVISION . BUILD
The following description is coming from the pdf file.
A Major Release is a full product release of the software. It generally contains new customer-facing functionality and represents a significant change to the code base comprising the software product or family of products, or is used to represent a significant marketing change or direction in the product. Major version numbers are generally incremented by the product management team, and generally are accompanied with a new
marketing push, or to communicate a significant improvement to the product. The major version number is identified by the digit or set of digits to the left of the decimal point (e.g., x.0, segment 1 with a placeholder value of x).
A Minor Release of the software may be comprised a rollup of several branched releases, enhancements/extensions to existing features or interfaces driven by internal or external requirements, external requirements could be driven by enhancements to meet new sales area (State specific features or rules), internal requirements could be enhancements aligned
to a new marketing push. The minor version number is identified by the digit or set of digits to the right of the decimal point separating it from the Major Release number (e.g., 2.x, x
indicates the Minor Release placeholder).
A Revision (Rev) is a build of all or part of the software that is initially distributed to an internal audience, specifically software quality assurance, for software validation. If the Rev is successfully validated and accepted, this version is “released” to manufacturing. If defects are found that prevent the Rev from successfully being validated and prevent the release to
manufacturing, the Rev value will be incremented prior to the next validation cycle.
A Build Release is a build of all or part of the software distributed to an internal audience, these releases should have targeted feature enhancements and issue resolution documented to allow testing in the targeted/specific areas where the changes were implemented. The Build version number is denoted by a fourth digit or set of digits (e.g. 2.4.7.x, segment 4 with a placeholder value of x), corresponding to an internal build number.
A completly other kind of versioning is the Calendar versioning. As it said in the name, we are using a date as version.
Depending the project, a lot of format can be used:
As you can see, you can add MINOR and MICRO if your date is too large and you have a lot of small releases to do.
And depending the kind of versioning you are using, you can use modifiers. It is a complementary element to your version.
MAJOR.MINOR.BUGFIX-MODIFIER
As you can see, the modifier is an element that you can add at the end of your version after a "-".
The major modifier are :
I hope it will help you!
Please don't hesitate to give me a feedback to improve my writing skills! Thanks!