12
I’m developing a project that serves as bootstrap for future contributions via Git, and would like to know which version scheme is most used, say "version" relative to the state the software is, example
version 0.1.1
Following the basic guidelines of versioning software
How to scale the version according to contributions? Using only branch’s and tag’s? Or there are other good practices?
12
A well-known model that many companies adopt is the Gitflow:
As you may notice, it covers much of the software development aspects: tags to mark versions, a branch of stable version (master), branch of development (develop), branch of activities (Feature branches), branch to corrections (Hotfixes) and so on.
Another link that I can tell you, which gives some more details of how this model works in practice, can be found here.
Although this model seems a bit bureaucratic, it helps to organize the software development process. Of course, you are not obliged to adopt this model rigidly, being able to flexibilize it according to the needs of your project.
About the number of versions, as stated earlier, is used the tags from Git to 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 may vary (0.1, v0.1, etc.), but note that it always occurs in the branch master, which is to be the stable branch of the system in this model.
If you have trouble following the model, the tool Sourcetree with the Gitflow plugin you can help you and your team. But I recommend understanding the template and not relying on tools of this type in the future. The ideal is for each team member to feel free to use the tool they find most suitable.
Absolutely. I found this model ideal and I will dry it according to the needs of my project. I only have one basic question, considering the MASTER branch as the main branch and also the branch that I launch the release TAG, will all sub releases that are between DEV and MASTER be merged into master by any member? or it would be a good practice to do the Approval of these Features in master through pull request?
At your discretion, but I think pull request useful. In the case of merge via pull request of the branches of the type Feature for develop, they can be performed by some member of the team who did not participate in the activity. It is possible to take advantage of this stage to make the code review of the code by who will make the Approval. Remembering that, in the proposed model, the only branches that merge directly with master are the release and Hotfixes.
Ball show, I’m gonna roll the pull request and for now I myself play the role of Approval. Thanks for your help, brother.
10
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".
very good your comment will surely help me to improve my knowledge and manage to launch this project so that other members can contribute in a unified way. I also prefer to work freely (without technology dependencies). I’ve already risked to see a project by the HASH of the commits, but it turned into cat cake, I do not recommend much, unless it is very specific. Thanks brother.
3
I will give a response based on the website proposal 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 standard MAJOR.MENOR.PATCH, increment:
- the LARGEST version when you introduce incompatible changes to the API,
- the SMALLEST version when you add functionality in a way compatible with what already existed (Backwards-compatible), 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 MAJOR format.MENOR.PATCH.
Browser other questions tagged git versioning
You are not signed in. Login or sign up in order to post.
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