All,
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?
- Thanks, Ken
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.
Did this version break your code?
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.
Koz,
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.
Koz,
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.
- Ken
Koz,
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.
Ken,
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.
For those of us watching Rails and ARel on GitHub, the necessity to track this change became apparent late in September. For those who weren’t, Aaron’s post at http://engineering.attinteractive.com/2010/10/arel-two-point-ohhhhh-yaaaaaa/ mentioned it explicitly a month ago.
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.
Pragmatic advice Aaron, thanks!
- Ken
Pragmatic advice Aaron, thanks!
- Ken
Pragmatic advice Aaron. Thanks!
- Ken
No problem. For some reason I have the "Priceline Negotiator" song in my
head now. 
No worries Ernie, just been one of those days.
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!
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks