I've pushed a 3.1.0.rc4. Please test it against your application against this release candidate and report any regressions to the [rails core mailing list](http://groups.google.com/group/rubyonrails-core). I would like to hear your feedback, good or bad. Especially if it's good. <3 <3
In two weeks, if there are no show stopping issues I will release the final version. If we do find regressions, I will publish another release candidate and we'll put another two weeks on the clock.
However, I will not wait two weeks between release candidates. I want to get the final done as quickly as possible, so I'll try to release RCs as quickly as possible.
## CHANGES
Here are some of the major changes to the RC branch:
I just noticed that the long overdue and inevitable reorganization of the test directories for ActiveRecord have changed since the first release candidate. Has this directory structure and new config/connection setup been done in such a way that allows adapters maintained outside of rails core to easily hook in? Case in point, the SQL Server adapter has always defined a rake test task that uses test libs and files in a rather clever way that set's the load path to leverage the AR test suite along side of a rich set of our own. I suspect other adapter projects have done this too.
So I am reading thru the changes and without much evidence I'm a little pessimistic that I'll be able to hook things up correctly from an outside in approach. For instance, the helper will require 'config' and that file in turn will set some various XYZ_ROOT constants. The problem is if I create a config.rb in my test root so that AR's helper loads mine and then I set my (for example) TEST_ROOT to my local directory, all the things in the load path for using things like FIXTURES_ROOT would not work. If you wondering why I would set something like TEST_ROOT to my local directory, it seems that this would be needed for support/config.rb to load my connection information. So it looks like I'm in a catch-22.
I suppose I could redefine a support/config.rb in my load path forcing that one to be used and just keep it slim and focused to just use ARTest.confg with my loaded configurations. Is this the suggested way? I'll let you know what I find out as I am trying to get my tests running again now. I ask for just a little bit of time while I cope with the changes. BTW, really excited about 3.1 releasing. The SQL Server adapter eats up the prepared statement support. Our speed benefits are just as high as PostgreSQL's
The change was done because we had a failing CI, which was failing
because each different branch was using the same database and conflicts
ensued (also this meant we could not build branches in parallel).
So the aim of the change was actually to make things *more* configurable
and so allow us to use different dbs for each branch.
To this end the test/config.yml file was added to allow you to configure
database connections. This file is .gitignore'd. There is a
test/config.example.yml file in the repo. The first time you run the
tests, the example config will be copied if the config file doesn't
exist already.
So, you should be able to set up your test connections for SQL server
within test/config.yml. Is this all you need?
Perhaps you need to be able to run a bit of code before the tests, to
require some files or add some workarounds or something? If so, possibly
we could add a simple hook mechanism. I.e. if
ARTest.prepare_connection_sqlserver is defined, and the DB connection in
use is 'sqlserver' (this is set by a ARCONN env var or by the
default_connection key in test/config.yml), then
ARTest.prepare_connection_sqlserver gets run at the beginning of
ARTest.connect.
TL;DR If the current system isn't configurable enough for your use case,
give me the gorey details and we can sort something out.
Have there been any showstopping issues since rc4? It’s been a couple weeks since the last rc and I’m wondering if there are any showstopping issues I can (if I’m lucky) help resolve. (Or is there some obvious way to know this on Github that I’m overlooking?)
In two weeks, if there are no show stopping issues I will release the
final version. If we do find regressions, I will publish another release
candidate and we'll put another two weeks on the clock.
However, I will not wait two weeks between release candidates.
Don't let everybody wait for updates. Just give us a short notice on
what's going on and what holding Rails 3.1 back..