On Wed, Jul 23, 2014 at 1:53 AM, Robert Coli <rc...@eventbrite.com> wrote: > On Tue, Jul 22, 2014 at 1:53 AM, Ben Hood <0x6e6...@gmail.com> wrote: > In this particular case, the answer to "why not" involves the idea that one > needs to be able to test with a driver in order to expose it, and currently > (as I understand it) only distributed tests use a driver. > > I believe that operators expect there to be a robust representative test > schema that can be created on version X.Y.Z and be accessed on version > X+1.y.0 which would exercise this core code and increase confidence that > tables created in major version X will always be usable without exception in > X+1.
With gocql we currently run out integration test suite on Travis against 1.2.18 and 2.0.9 (*), but in each case, we install the server from a clean slate. Theoretically we could do a migration, but the clean slate makes things easier for us. One could argue however that verifying server migration is beyond the scope of the integration test suite for a client driver. (*) We've looked at including 2.1rc3, but there is a acknowledged server side bug that causes one of our tests to fail, so we do not have mainline coverage for 2.1-rcx yet.
