cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Witschey (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10269) Run new upgrade tests on supported upgrade paths
Date Tue, 08 Sep 2015 18:20:46 GMT


Jim Witschey commented on CASSANDRA-10269:

Ok, it sounds like the paths we want to test right now are

- 2.1->3.0
- 2.2->3.0
- 3.0->trunk

I'll have these paths run in the dtests for 2.1, 2.2, and 3.0, respectively. To add coverage
for the dev branches, I'll also run 2.2->HEAD on the trunk dtest jobs. As mentioned earlier,
that shouldn't make the jobs take prohibitively long, but if it does, we can get rid of that
as well.

At some point we'll need to fill out a proper matrix of upgrades from 3.X to 3.Y as Aleksey
described. For now, and I believe until 3.1 is released, this will give us the coverage we

> Run new upgrade tests on supported upgrade paths
> ------------------------------------------------
>                 Key: CASSANDRA-10269
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tests
>            Reporter: Jim Witschey
>            Assignee: Jim Witschey
> The upgrade dtests for 8099 backwards compatibility (originally dealt with in [this dtest
PR|] and [this JIRA ticket|])
need to be run with upgrades over the following upgrade paths:
> - 2.1 -> 3.0
> - 2.2 -> 3.0
> - 3.0 -> trunk
> There are a number of ways we could manage this. We could run the tests as part of the
normal dtest jobs in 2.1, 2.2, and 3.0, and select what version to upgrade to based on the
version of the test. We could also refactor the new upgrade tests to use the upgrade machinery
in the existing upgrade tests.
> [~philipthompson] [~rhatch] Do you have opinions? Can you think of other options?

This message was sent by Atlassian JIRA

View raw message