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