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.

Versioning System

3 digits versioning

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 feature

Semantic Versioning

If 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 change

4 digits versioning

Another 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.

Calendar versioning

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:

• Windows : YY/YYYY -> 95, 98, 2000
• Ubuntu : YY.0M -> 16.04
• JetBrains : YYYY.MINOR.MICRO -> 2017.1.2
• ...

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.

Modifiers

Alpha-beta-RC

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 :

• Alpha : For an internal release to do white box tests
• Beta : For a release which can be accessible to customers and we know that several errors can exists
• RC (Release Candidate) : Is a beta version which we think stable to be delivered in production.

I hope it will help you!

Please don't hesitate to give me a feedback to improve my writing skills! Thanks!