thesp0nge's tumblelog

Your awesome Tagline

14 notes

Choosing a good version numbering policy

Well, starting an opensource project is always somewhat challenging… you have to find a good name, may be a great logo ad you have to choose a good version number policy.

First of all… let’s use a decent branching model.

The ‘master’ branch will be the one containing the code marked to be production ready in a given moment. ‘master’ must be always compilable.

Code in the ‘master’ branch must have an even tag number.

Branches cannot created from ‘master’ except for hotfixes. Hotfixes branch will be named ‘hotfix_id’ where id will be a incremental number for issues.

Of course ‘lab’ is a branch from ‘master’.

The ‘lab’ branch will be the the place where developers will stay most of times, writing new code and pushing fresh code.

Code in the ‘lab’, will compile must of times and it will be merged in ‘master’ only after a code review and a regression tests run.

'lab' branch can have a lot of sons for each mainstream feature we're going to develop in aurora.

Code in the ‘lab’ branch will have an odd tag number.

Code in ‘features’ branch will have be tagged with the same name used for the branch.

For the version number, it will be created using the git describe command, since it’s a sort of standard de facto.

I’ll use infos from this blog post.

In fact, I’ll create a git hook that creates a version.h file with the git describe output. I have to link this info to the AC_INIT call in the configure.ac to backport it. I’ll check this out later how to achieve this.

Filed under versioning git branch

  1. thesp0nge posted this