> assumptions to scenarios: This is a mature gem used by lots of people.  It no doubt will be maintained long term ar-sqqserver-adapter
> E
> second assumption is changesets are not going to be very fast or change dramatically
> 4 is the other PR which is a lot of code and we are on hook for an inevitable drift
> #4 that is
> They have lots of MSQL apps and are willing to help support it
> This is a real scenario
> scenario #3 is to have ar-sqlserver-adapter put out jruby gem.  Seems not possible given their desires
> scenarion #2 is their cext gem does release a jruby .gem but it never changes  and has nothing in it
> I suspect this is undesirable on their side but on the edge of possibility
> #1 is to fork ar-sqlserver-adapter and upstream PRs when they can be added without being java/cruby branches (I think like your current PR to them on column_name/table_name)
> This would mean that fork would need to fetch/merge over time with changes from parent but due to assumptions above will not be a big duty
> #1 is possible and its difference with #4 is that their is a distinct barrier on tracking upstream code versus having made partial copies of that project
> That will make it easier to not drift
> #4 has an advantage that it need not fit into the shape of what ar-sqlserver-adapter delivers
> I suspect that is not much of an issue though since all our adapters fir AR as a native adapter shape already
> FIN

headius kares  any thoughts on this?