How does version naming work for private or public projects?

A well known model that many companies adopt is GitFlow :

Asyoucansee,itcoversmostaspectsofsoftwaredevelopment:tagstomarkversions,abranchofstableversion(master),branchofdevelopment,branchofactivities(featurebranches),branchforfixes(hotfixes),andsoon.

AnotherlinkIcangiveyou,whichgivessomemoredetailsonhowthismodelworksinpractice,canbefound here .

Although this model seems a bit bureaucratic, it helps organize the software development process. Of course, you are not required to adopt this model in a rigid way, and you can flex it according to the needs of your project.

On the number of versions, as mentioned before, the% git% is used for this. An example, creating version 0.1:

git tag -a 0.1 -m "Versão 0.1, com melhorias na consulta de pessoas"

The version nomenclature itself can vary (0.1, v0.1, etc), but notice that it always occurs in the tags branch, which is to be the stable branch of the system in this template.

If you have trouble following the template, the SourceTree tool with the GitFlow plugin will help you and your team. But I recommend understanding the model and not relying on such tools in the future. Ideally, each team member feels free to use whatever tool they think is most appropriate.

You can not say which is the most used, and even if you give this would not serve you.

There are some guidelines that can be adopted within what you use, but you can choose the best shape for your project. If other people are expected to contribute, maybe they will want to influence it.

Start doing it in a way, if it does not work, change. Only experience can determine the best way for each project.

It has languages or technologies that indicate a way to do it.

There is a list of different ways in Programmers . I put a date-based versioning response that might be useful in certain scenarios and it was well voted.

If you want to know about the Semantic Version you already have a question about it . He seems to be being adopted more now. But as my answer there indicates, the exact point of exchange is subjective. You can only determine general lines.

The page you mentioned already gives you other ways and you can search for projects in public repositories in other ways.

Some people like letters as well. Or negative numbers more rarely. Some use numbers with some specific meaning.

Some prefer very complicated schemes. It's valid, but unless you have a good reason for this, I suggest avoiding it. It is almost always an unnecessary complication and little or no advantage. The same goes for frequent exchanges that make the numbers high. Remember that you will speak, write and manipulate this designation a lot. Facilitate.

If you want to change the version whenever you want, it can and does work. Just do not go make new versions by decreasing numbers, it creates confusion. The rest is like adapting to the flow that you think will suit the team better.

Remembering that you can have different nomenclatures for internal project use and for "commercial" disclosure.

I will give you an answer based on the proposal of SemVer.org ( semantic versioning ):

  

Given a version number MAJOR.MINOR.PATCH, increment the:

     

• MAJOR version when you make incompatible API changes,
  
• MINOR version when you add functionality in a backwards-compatible manner, and
  
• PATCH version when you make backwards-compatible bug fixes.
  

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Translation:

  

Given a version number in the MAIOR.MENOR.PATCH pattern, increment:

     

• THE LARGER version when you introduce incompatible changes in the API,
  
• MINOR version when you add functionality in a backwards-compatible way, and
  
• the PATCH version, when you introduce patches compatible with what already existed.
  

Additional tags for pre-release information and build data are available as extensions to the MAIOR.MENOR.PATCH format.