You can’t tell which one is the most used, and even if you gave it, it wouldn’t do you any good.
There are some guidelines that can be adopted within what you use, but you can choose the best shape for your project. If you expect other people to contribute maybe they’ll want to influence this.
Start doing it one way, if it doesn’t work, change it. Only experience can determine the best way for each project.
It has languages or technologies that indicate a way of doing.
There’s a list of different forms in Software Engineering. I put a response with versioning based on dates that may be useful in certain scenarios and it was well voted.
If you want to know about the Semantic Version already has a question on the subject. It seems to be being more adopted now. But as my answer there indicates, the exact point of exchange is subjective. It can only determine general lines.
The page you mentioned already gives other ways and you can search projects in public repositories in other ways.
Some people like to put letters as well. Or negative numbers more rarely. Some use numbers with some specific meaning.
Some use the hash of commit that generated a tag in Git to help locate in the repository. It depends on how it works may be useful but is often redundant since the tag should contain the version information. In some cases you can use the branch also, but it’s confusing. In general, only tags should have versions (even in the SVN). Exception maybe when the branch be created to organize a release or at least builds.
Some prefer very complicated schemes. It’s valid, but unless you have a good reason for it, I suggest you avoid it. Almost always an unnecessary complication and little or nothing advantageous. The same goes for frequent exchanges that make the numbers high. Remember that you will talk, write and manipulate this designation a lot. Facilitate.
If you want to change the version to the time you want, it can and it works. Just don’t create new versions by decreasing numbers, it causes confusion. The rest is to adapt to the flow you think best suit the team.
Remembering that you may have different nomenclatures for internal project use and for dissemination "commercial".
Are you looking for something like this? http://nvie.com/posts/a-successful-git-branching-model/ . Here are more details: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/. If it is, I’ll provide you with a more complete answer.
– Dherik
Thank you @Dherik is exactly the concept I need to organize the project, it’s less than I imagined, but I needed a professional example. vlw
– Kaio Cesar
Take a look at [tour]. You can accept an answer if it solved your problem. You can vote on every post on the site as well. Did any help you more? You need something to be improved?
– Maniero