ZF2 modules project "coolcsn". Git branching model. Semantic Versioning.

Our ZF2 modules project "coolcsn" starts to take off. Its goal is to provide the community with reusable FZ2 modules, which allow everyone to build a CMS/Blogging, e-commerce etc.  within 5 minutes.

There is a YouTube tutorial on the same topic I am discussing here in this blog post "ZF2 modules coolcsn. Git branching model. Semantic Versioning. How to use or participate?". There you can see how the 2 Git branching models can be implemented.

"Joomla" and "WordPress" are very good examples of CMS/Blogging solutions. But we want to have behind the flexability and power of Zend Frameowrk 2.

We are building the modules with students. They constantly come and go. We have to offer a really simple Git branching model for people which almost don't know what SCM system is.

All we want is to code. Git is a tool. It should stay out of the way. It should be transparent.

When I want to take shower I don't want to know how the boiler works. All I want is simply to take a shower.

I am coming from the world of SVN. It did its job for us. It was transparent.

The last years I switched to Git. We are using it for all our projects. It offers a lot. But sometimes "more is less". There is " The paradox of choice". More choices you have, more time you have to spent on making choices and less time to do your real job and enjoy the life.

Since the branches in Git are so cheap how can we take advantage of that? We have to figure out a branching model for our projects.

The first one was "A successful Git branching model". I love it because instead of inventing everything from scratch the solution was given to us.

The people don't like to "rethink". They don't like to think at all. Thinking requires energy and time.

"A successful Git branching model" is robust and obviously works. Many people left positive comments in Internet. But many try to find simpler solutions.

Also I think this model is good for well established professional software teams. We are looking for something that doesn't have to be explained and doesn't require thinking, time and knowledge at all. "Less is more"!

Also our project is Open Source. Many people should be able to just, fork, code and send PR (Pull Request). This is the reason, I think  having, only one branch in the public repository (master) will make the think easier.

I came across a branching model suitable for PHP, OSS, composer projects "Git branching model". It works very well with "composer" as well. And it is relatively new. The post is from October 21, 2013.

 I like it because it is simpler. It uses master branch for development and the tags for releases. I still have some questions, but the model looks good.

What bothers me is the fact that master branch means 2 things. "But 'latest' can mean one of two things. Either it is the development of a yet unreleased version. Such as 1.1-dev which will eventually become v1.1.0. Or alternatively there could already be a release on 1.1, and this would be the development of the next release, such as v1.1.1." What it is finally? How can you tell?

In any case I like it because unlike "A successful Git branching model", "Git branching model" uses master for actual development.

In  "A successful Git branching model" master branch is used only for releases. In fact each commit in the master branch represents a release, together with a tag.

The people who try to improve "A successful Git branching model" usually reduce the number of the branches.

In "Git branching model" for each minor release we have to have a branch. I guess it should be in the origin repository. That means we can end up having a lot of release branches in "origin" repository. But it makes sense to have publicly available branches for the releases because in OSS many different people, which don't know each other, will work on the release.

There is a very interesting post "What git branching models actually work?". The guy has done a good research.

The version of the release is another interesting question. But we have a much clear answer to it. I like standards. They allow me to think less. They don't give me too many choices. Another words they give me more. Fortunately there is a standard for the versions of the releases. "Semantic Versioning 2.0.0" is the standard. It is clear and simple. We will follow it.

It seem so me Zend Framework team is using "A successful Git branching model". If you look their repository you will see 2 branching living together int he origin repository - "master" and "develop". This is what suggests "A successful Git branching model"

 It is hard to say what git model zf-common  implements. Each module usually has only master branch and tags representing different releases. Many don't even have tags. I like this simplicity.

Summary :
I would say, lets have only "master" branch in the "origin" repository for each CSN module. For each release we will have a tag. The "Semantic Versioning 2.0.0" will determent the version of the release.

If there is a need to create branches for different releases we will implement "Git branching model".

If we have a dedicated team in the future we can implement  "A successful Git branching model".