How are the versions of a program identified?

While there are several conventions with different approaches, one of the commonly accepted is major / minor / patch

• First number: corresponding to the version, every change that makes the device incompatible backwards represents an increase in this number.
• Second number: corresponding to large changes or importance, such as new system modules or functionalities
• Third number: corresponding to bug resolution mainly.

More info:

What naming convention do you use? Semantic versioning

Since enough theory has already been planted here, I will just limit myself to specifying an example of use using the methodology MAYOR.MINOR.PATCH

Imagine that you have created a library that has the following functions implemented:

StackOverFlow::crearPublicacion(mensaje)
StackOverFlow::editarPublicacion(id, mensaje)
StackOverFlow::comentarPublicacion(id, mensaje)

As it is your first proposal to the world, you are baptized as Version 1.0

After a while you decide that you want to add more functions, now you would have something like that in total

StackOverFlow::crearPublicacion(mensaje)
StackOverFlow::editarPublicacion(id, mensaje)
StackOverFlow::comentarPublicacion(id, mensaje)
StackOverFlow::puntuarPublicacion(id)                     // Nueva función

Since the above was just an addition of a new feature it does not affect who is using your library, so you baptize your new post as Version 1.1

StackOverFlow::crearPublicacion(mensaje)
StackOverFlow::editarPublicacion(id, mensaje)
StackOverFlow::comentarPublicacion(id, mensaje)
StackOverFlow::puntuarPublicacion(id)
StackOverFlow::puntuarComentario(id)                      // Nueva función
StackOverFlow::publicarRespuesta(id, idPregunta)          // Nueva función
StackOverFlow::aceptarRespuesta(id)                       // Nueva función

You use this same version increase for all your posts that provide the sum of features Version 1.2

Now it happens that at some point, users of your library find errors, errors that you must correct

StackOverFlow::crearPublicacion(mensaje)
StackOverFlow::editarPublicacion(id, mensaje)
StackOverFlow::comentarPublicacion(id, mensaje)
StackOverFlow::puntuarPublicacion(id)
StackOverFlow::puntuarComentario(id)                      // Función corregida
StackOverFlow::publicarRespuesta(id, idPregunta)
StackOverFlow::aceptarRespuesta(id)              

Then because this does not add features but rather is attributed as a patch to an error you had in production, you name it Version 1.2.1

Then you realized that to append some feature or simply to improve the library you must restructure the syntax of some functions

StackOverFlow::crearPublicacion(mensaje)
StackOverFlow::editarPublicacion(id, mensaje, idUsuario)  // Función con cambios
StackOverFlow::comentarPublicacion(id, mensaje)
StackOverFlow::puntuarPublicacion(id)
                                                          // Función eliminada            
StackOverFlow::publicarRespuesta(id, idPregunta)   
StackOverFlow::puntuarRespuesta(id, idPregunta)
StackOverFlow::aceptarRespuesta(id)                       // Nueva función

However, this time the users who are using your library will find that their programs will be broken because one of your functions now demands a new parameter or they simply implement a function that you already eliminated, to prevent these problems you decide to baptize the publication as Version 2.0 , restarting the marking of the sections MINOR and PATCH and continuing the process carrying the same logic.

In summary:

• MAJOR is only edited when the new features in the development to be proposed as publication lead to failures due to new ways of implementing the methods, removing functions or even changing names of these.
• MINOR is edited for each publication that expresses new features, which lead to improving and expanding your project, without affecting the existing functions.
• PATCH is edited in every correction you make in production, that is, the changes you make to correct errors in previous posts.

It's a bit direct, but I hope it's understood.

Introduction to versioning

It depends mainly on the project. but in general they are identified univocally, that is to say, each version has its own identifier that distinguishes it from others, they can be numbers, names, symbols, etc.

The simplest way to control the versions is with an incremental number per change made. For example

objetov1 refers to version 1 of objeto
objetov2 refers to version 2 of objeto
...
objetovi refers to version iésima of objeto

This version system is enough for most objects, for example imágenes , libros , documentos , etc.

Semantic versioning

However, in the software it is not enough to just identify a version, we need to know other things eg: Which versions are compatible? What versions represent arrangements in the code (bugs, format, etc)? versions represent improvements regarding functionalities?

As you can see, now we must have control of 3 aspects, so we represent the versions as

MAJOR.MINOR.PATCH
The idea is the same, for each change you must increase a number, according to the following rules

MAJOR represents compatibility (objects with same MAJOR are compatible)
MINOR represents compatible changes within MAJOR
PATCH represents fixes in the code.

It should be mentioned that any MAJOR.MINOR is compatible with MAJOR'.MINOR' yes and only yes MAJOR = MAJOR' , and MINOR <= MINOR' , for example 2.3 is compatible with 2.4 but not vice versa, 2.4 is not compatible with 2.3 .

For more information you can check the link to semantic versioning

Well, this version is useful when someone else uses your code as a dependency of your project, I speak mainly of code, because originally it was talking about compatibility in the ABI (binary), however the term was extended to the API (interfaces ). In other words, what is sought is that third parties can analyze your changes, and depending on what they are, migrate without risks, since an unsupported change can break the functionality of the application that depends on it.

Other types of versioning

However, the semantic versioning is a burden, when all the versions are incompatible with each other, so many projects decide to use another type of versioning that suits them, an example of this is Mozilla and Chrome that their versions are mainly based on time lapses, however its version is compatible with semantic versioning, but we will never see changes in its MINOR , they do not use it.

Another example is TeX , which for me is one of the most creative, the versions of TeX are decimals of the number PI , the last stable version of TeX is 3.14159265

Conclusion

Each project can choose its own versioning system, so the only way to verify compatibility is by reading the change log (Change history), and the correct programmer's notes.

Good! each time the programming team makes changes to the program and believe they have to make it available to users, they release a new version with the changes made. It is a way of knowing which version to use, the more recent the more recent it is and it may work better. each version that comes out, they change the version number. The number is chosen by them .. there are sites that make v1.0, v1.1, v.1.2 ect .. or v1.0, v.2, v3.0