Skip to Content.
Sympa Menu

freetds - Re: [freetds] server realm configuration for ODBC

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Ken Collins <ken AT metaskills.net>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] server realm configuration for ODBC
  • Date: Sat, 10 Mar 2012 16:32:35 -0500


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





Archive powered by MHonArc 2.6.24.

Top of Page