On Fri, Jan 9, 2015 at 9:04 PM, Philip Thompson <
philip.thomp...@datastax.com> wrote:
> but will only be applicable for
> a particular slice of C* versions, e.g. 2.0.X < x < 2.1.3.
>
But converting some dtests into unit tests shoudn't invalid the dtests, so
those dtest could still be left in. I
The change that prompted the idea is CASSANDRA-8454. As we attempt to move
cql_tests.py and other single node, CQL based dtests into unit tests in 2.1
and 3.0+, we will have a large number of tests, in the low hundreds, that
not only have minimum version restrictions, but will only be applicable fo
On Thu, Jan 8, 2015 at 2:23 PM, Philip Thompson <
philip.thomp...@datastax.com> wrote:
> I expect the benefits to grow as we make more radical changes
> to cassandra-dtest for cassandra 3.0.
>
What kinds of changes are you planning? Perhaps we can come up with good
alternatives.
--
Tyler Hobb
I happen to see the fact that the differences between C* version are clearly
visible for a given test as a feature rather than a burden. Every
difference in
behavior between C* versions should have a good reason, and I like that
dtests
highlight them. Typically, from very quickly eyeballing the pat
All,
I would like to propose splitting the cassandra-dtest code base into
versioned branches that match the structure of the C* repository. Each C*
version branch, e.g. cassandra-2.0, would have a corresponding dtest
branch. This will allow us to isolate version specific changes to their own
branc
