FreeTDS Development Group

[Ken Collins <ken AT metaskills.net>]

First, I tend to follow a semantic versioning policy (http://semver.org/) and 
follow others best practices. But what works for me is generally tied to the 
success of rubygems as a whole. So my system(s) general reflect other 
projects in the same sphere. I think a good example is the rails project.

https://github.com/rails/rails

So they have been using git since version 1.2.x I think. If you look at their 
branches you can see how that have a "major-minior-stable" for each count 
since they moved. The master branch is a moving target to that next branch 
philosophy. In this case, mast of the rails repo is going to be the future 
4.0 version, but they are still doing security released to "3-1-stable" and 
their latest minor "3-2-stable". In fact, I suspect there will be another 
3.2.x version release before 4.0 is released. So that work happens on the 
"3-2-stable" branch. It just so happens that I am the author the SQL Server 
adapter for ActiveRecord. And my repo has a primary dependency on 
Rails/ActiveRecord and hence I follow a semantic versioning policy that 
tracks that primary dependency. I also structure my branches in such a way. 
So for example, these two branches still get work and point "patch" releases 
from that branch.

https://github.com/rails/rails/tree/3-1-stable
https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/tree/3-1-stable

I also git tag all versions too that are of the format "vN.N.N". A tag does 
not have to happen on master. In fact, many can not. It is just a ref to any 
place in the repo. So if Rails and myself were to release a 3.1.x updated 
patch version. That work would happen on the "3-1-stable" branches and the 
git tags would be from there too. In this way we get to cherry pick commits 
that may be from any other place and be a bit more agile about how we work. 
This may look a little complicated, but it is pretty simple once you get used 
to it. Hope that is helpful info.


 - Ken