Major.Minor.Patch

Major.Minor.Patch


Every time you release a public (API) software you must update his version number.

The (public) version is universally composed by 3 numbers separated by a point:

Each version number has a semantic representation

The pattern is 

Major.Minor.Patch

Ex: in version number 10.2.5

10 is the Major version

2 is the Minor version

5 is the Patch version

All of these 3 numbers are always 

Incremented

NEVER decremented

Positive starting by 0

Patch number

It is incremented each time the release is about fixing some bug without affecting the already existing public interface

So if you see a version number like: 1.1.5 it means the last 5 releases were about fix bugs.

Minor number

As opposed to Patch, Minor means that they have been released new (interesting) public feature, without impacting old ones.

When there is a new Minor release the Patch number is restarted to 0. Of course, together to new feature, it’s possible that also some bug fixes have been released (even though the Patch number is 0)

Major Number

When the Major number is incremented the release contains new (fantastic) features, buuuut it means that all the old features are not anymore compatible! So if you depend on those, pay attention.

If you think about it, these versioning rules could be applied also to humans.

Each 1st of January we always have new proposals for our self, so it’s like we “would” change our Major version. Or whenever we learn something new we could upgrade our Minor version.

But when do we change our Patch Number? Maybe each time we have makeup?

0 Comments

Add Your Comment: