Re: server realm configuration for ODBC

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