Now if I don't ask for a specific version (by removing the --version
option above), I get the very latest point revision in the repository,
which is 1.0.0.9216, along with the latest point revisions of both
activerecord and activesupport (2.0.2.9216).
I'm not interested in being this "close to the edge".
Is there any way that I can get the 1.0.0 version of the SQLServer
adapter?
Thanks,
Wes
P. S. Somewhat related (given the point releases above) is that once I
install this adapter, gems.rubyonrails.org is automatically added to my
sources for gem, and then if I ask for a gem update for Rails, I will
get the very latest point release of all of the Rails components.
Again, I really don't want them. I have to remove the
gems.rubyonrails.org source to keep this from happening.
Download the source from svn/github and build it yourself? I would
imagine the 1.0.0 release would have been tagged (and if not you
should be able to work out when it what revision corresponds to the
release).
Is there an official released version of the SQL Server adapter? I was
assuming it's 1.0.0, but maybe it's not, maybe it's 1.0.0.9216. (I
wonder if this is the case for all non-standard AR adapters)
If it is 1.0.0.9216, then I assume I need to use this point rev. of
Rails, which is 2.0.2.9216.
Are these point releases stable or are they nightly snapshots? I've
It's not even a nightly snapshot - it just means revision 9216 from
svn. The reason that the gems get the revision number appended is
basically so that the next version of rails looks like a newer version
(ie 2.1 > 2.0.2.9216).
The whole point of ousting the adapters out of core was so that
development and release of these adapters is not tied to the same
release schedule as the rest of rails. As it happens, subversion seems
to say that the sqlserver adapter basically hasn't changed since 2.0.0
was released (ie 1.0.0 of the adapters) (just a missing require
somewhere) and so you'd be perfectly safe using the latest and
greatest, and that would not require you to run edge rails itself (and
if the gem itself says so you should be able to fix that quite easily.
heard too many stories of people on edge who waste hours tracking down
bugs that someone checked in to edge. If these are snapshots that are
very close to edge, I'm not really interested in developing against
"nightly build" type releases if I can avoid it. Perhaps I'm being too
conservative.
It's understandable. I don't run production stuff against edge.
Sure, I can look around in the SVN/github repo. and find what I need
myself, but I feel like the distribution of the SQL Server adapter
should be a little more straightforward that that.
Arguably, but these sort of things are very much dependent on whether
someone steps up and handles these sorts of issues, so hassle the
maintainer, volounteer to help out yourself etc...
It's not even a nightly snapshot - it just means revision 9216 from
svn. The reason that the gems get the revision number appended is
basically so that the next version of rails looks like a newer version
(ie 2.1 > 2.0.2.9216).
So this means these "release numbers" basically identify individual
builds?
The whole point of ousting the adapters out of core was so that
development and release of these adapters is not tied to the same
release schedule as the rest of rails.
I definitely get this, and agree with the new setup. But it seems like
when the adapters got pulled out of Rails, they were not themselves
"promoted" to units of software that are released, just like
activerecord, actionpack, etc. To me, since they were basically
extracted out of activerecord, they should be managed in the same way
from a release perspective.
Sure, I can look around in the SVN/github repo. and find what I need
myself, but I feel like the distribution of the SQL Server adapter
should be a little more straightforward that that.
Arguably, but these sort of things are very much dependent on whether
someone steps up and handles these sorts of issues, so hassle the
maintainer, volounteer to help out yourself etc...
I wonder if this shows up as an issue with the other "second tier" AR
drivers,
I will try and check a couple out. I'm willing to help, but it kind of
feels like this is the job or whoever maintains the package, so I either
need to get them to do it, or become that person.
It's not even a nightly snapshot - it just means revision 9216 from
svn. The reason that the gems get the revision number appended is
basically so that the next version of rails looks like a newer version
(ie 2.1 > 2.0.2.9216).
So this means these "release numbers" basically identify individual
builds?
Yup. Individual check-ins (9216 is the latest you'll see though now that rails has moved to git)
The whole point of ousting the adapters out of core was so that
development and release of these adapters is not tied to the same
release schedule as the rest of rails.
I definitely get this, and agree with the new setup. But it seems like
when the adapters got pulled out of Rails, they were not themselves
"promoted" to units of software that are released, just like
activerecord, actionpack, etc. To me, since they were basically
extracted out of activerecord, they should be managed in the same way
from a release perspective.
I think it's just lack of love. For the sql server adapter at least, there's only been a handful of commits. I know for a fact that AR's unit tests are currently most likely broken for sql server (because I broke them)