I really do think the latest 3.0.2 version was poorly chosen.
A "major" version of 1.x to 2.x of Arel should have at least affected the "minor" version of rails/activerecord, not "tiny". As an author of an external adapter, I set my gemspec expecting such to give me time to account for the rewrite. A version change of 3.0.1 to 3.0.2 should not break my code. Thoughts about this for future versioning?
In my opinion, the Rails version number should reflect the changes to
the Rails API. The user-facing API did not see major changes due to
the ARel rewrite.
As the author of two gems (MetaWhere and MetaSearch) that are heavily
dependent on ARel for their functionality, I released updated gems an
hour after 3.0.2 released, having been tracking the changes since
Aaron started the rewrite.
I didn't find the changes to be too troublesome to track, and the
payoff was certainly worthwhile. Where I encountered missing or
changed functionality I submitted patches to ARel to reduce/limit
breakage. See http://metautonomo.us/2010/10/15/converting-your-code-to-arel-2-0/
for a writeup about some of the stuff I encountered, if you're
curious. Aaron has been great about merging pull requests in a timely
manner, in my opinion.
I think anyone who maintains code that integrates with a lower-level
API like ARel owes it to themselves to track major version changes in
those dependencies, not just Rails.
I agree with Ernie here, while the ARel changes are huge they're
largely user-facing compatible, and for the rails api they're
completely compatible. Barring bugs (and I believe we've found one)
everything should work just fine. Because of that, the tiny version
number bump seems appropriate.
I can understand what your saying, especially from the internal interfaces of ActiveRecord to Arel and within the databases supported as part of rails core. But that should not be the only decision maker for a gem versioning policy.
ActiveRecord/Arel are so tightly bound that a major version of one should have affected the minor version of another. Especially from the perspective of external adapters (compilers/visitors) that are trying to do the right thing by following a rational versioning policy. I set my activerecord-sqlserver-adapter gem dependency to activerecord ~> 3.0.0 and with the way the current release was handled, there is no way an external adapter can cope with the change of ActiveRecord 3.0.1 to 3.0.2. All I am asking is that core consider a gem version that makes sense to external libs, in this regard ActiveRecord is kind of unique and should have wagged the dog of rails to 3.1 along with it.
Lastly (@Ernie), I do not think it’s fair to say, just get your update out. Those who know me, know that I spent way to much of my free time writing open source code for the benefit of the rails eco-system, almost to a fault. This is about a versioning policy that should have allowed me to roll with the punches while I spend a few weeks focusing on my personal projects.
I can understand what your saying, especially from the internal
interfaces of ActiveRecord to Arel and within the databases supported
as part of rails core. But that should not be the only decision maker
for a gem versioning policy.
ActiveRecord/Arel are so tightly bound that a major version of one
should have affected the minor version of another. Especially from the
perspective of external adapters (compilers/visitors) that are trying
to do the right thing by following a rational versioning policy. I set
my activerecord-sqlserver-adapter gem dependency to activerecord ~>
3.0.0 and with the way the current release was handled, there is no
way an external adapter can cope with the change of ActiveRecord 3.0.1
to 3.0.2. All I am asking is that core consider a gem version that
makes sense to external libs, in this regard ActiveRecord is kind of
unique and should have wagged the dog of rails to 3.1 along with it.
Lastly (@Ernie), I do not think it's fair to say, just get your update
out. Those who know me, know that I spent way to much of my free time
writing open source code for the benefit of the rails eco-system,
almost to a fault. This is about a versioning policy that should have
allowed me to roll with the punches while I spend a few weeks focusing
on my personal projects.
I can understand what your saying, especially from the internal
interfaces of ActiveRecord to Arel and within the databases supported
as part of rails core. But that should not be the only decision maker
for a gem versioning policy.
ActiveRecord/Arel are so tightly bound that a major version of one
should have affected the minor version of another. Especially from the
perspective of external adapters (compilers/visitors) that are trying
to do the right thing by following a rational versioning policy. I set
my activerecord-sqlserver-adapter gem dependency to activerecord ~>
3.0.0 and with the way the current release was handled, there is no
way an external adapter can cope with the change of ActiveRecord 3.0.1
to 3.0.2. All I am asking is that core consider a gem version that
makes sense to external libs, in this regard ActiveRecord is kind of
unique and should have wagged the dog of rails to 3.1 along with it.
You tie your version to ARel *and* ActiveRecord, not just ActiveRecord.
It's fine for you to say AR is ~> "3.0.0", but you should not ignore the
version number of ARel. You depend on ARel, and your gem dependencies
should reflect that.
Lastly (@Ernie), I do not think it's fair to say, just get your update
out. Those who know me, know that I spent way to much of my free time
writing open source code for the benefit of the rails eco-system,
almost to a fault. This is about a versioning policy that should have
allowed me to roll with the punches while I spend a few weeks focusing
on my personal projects.
Release a bugfix version that depends on AR ~> 3.0.0 and ARel ~> 1.0.0
and you should be fine.
Some clarification is in order. I meant no disrespect in my response. I empathize with your investment of free time, and I certainly never said “just get your update out.” My point was that this shouldn’t have taken anyone who maintains a gem that depends on ARel by surprise. I intended to give practical advice for avoiding this type of thing in the future as a gem author.
I stand by my original statement that the Rails version number followed solid semantic versioning principles by incrementing patch, and not minor, level.
Sorry if there was any misunderstanding. As someone who was once stuck coding in an MS ecosystem, I greatly appreciate the efforts of anyone willing to undertake the effort to maintain an adapter for SQL Server. If you need any help figuring out the layout of ARel 2, please drop me an e-mail. I’ve spent enough time digging around in it and submitting patches in both 1.x and 2.x that I should be able to help. That failing, Aaron’s always been very responsive, in my experience.
I too, have been following Aaron’s move on ARel for a long time too. I just choose to learn C extensions in the past 6 weeks so I could provide a different connection mode to the adapter that had strong encoding support, native ruby bindings, etc. A gem called TinyTds binding to FreeTDS’s DB-Library interface.
Aaron’s been uber helpful too and we even got to chat about this release and future ones while at RubyConf. ARel and ActiveRecord are really straight forward code bases, it is only an issue when needing to bend SQL Server to their will, my burden tho.
I too still stand by my opinion that ActiveRecord and ARel are tightly coupled enough that a major version change of one should have driven the other. Technically a compound approx tiny version dep as Aaron said will address my issue, but it feels wrong to me. OK to disagree, just sharing my thoughts. Thank you very much for the offer to help too!