absurdfarce commented on code in PR #1936:
URL:
https://github.com/apache/cassandra-java-driver/pull/1936#discussion_r1626161031
##########
Jenkinsfile:
##########
@@ -414,11 +414,11 @@ pipeline {
# Every weeknight (Monday - Friday) around 2:00 AM
### JDK8 tests against 2.1, 3.0, DSE 4.8, DSE 5.0, DSE 5.1, dse-6.0.18
and DSE 6.7
H 2 * * 1-5 %CI_SCHEDULE=WEEKNIGHTS;CI_SCHEDULE_SERVER_VERSIONS=2.1 3.0
dse-4.8.16 dse-5.0.15 dse-5.1.35 dse-6.0.18
dse-6.7.17;CI_SCHEDULE_JABBA_VERSION=1.8
- ### JDK11 tests against 3.11, 4.0 and DSE 6.8
- H 2 * * 1-5 %CI_SCHEDULE=WEEKNIGHTS;CI_SCHEDULE_SERVER_VERSIONS=3.11 4.0
dse-6.8.30;[email protected]
+ ### JDK11 tests against 3.11, 4.0, 5.0-beta1 and DSE 6.8
+ H 2 * * 1-5 %CI_SCHEDULE=WEEKNIGHTS;CI_SCHEDULE_SERVER_VERSIONS=3.11 4.0
5.0-beta1 dse-6.8.30;[email protected]
Review Comment:
The convention that appears to be in play here is an older OSS Cassandra
version (3.11) + a newer one (4.0) + a reasonably recent DSE version. My first
thought was to just _replace_ 4.0 with 5.0-beta1 but as I think about it now I
don't think that's right. We want nightlies to provide a meaningful reference
point so we should aim for something like:
* Test the oldest supported JDK (currently Java8) against a lot of versions,
specifically older versions
* Test other LTS JDKs against and older OSS Cassandra release, a newer one
and a reasonably new DSE release
The suggestion here seems to be that we should make Cassandra 4.1 the newer
OSS Cassandra release, meaning we replace 4.0 with 4.1 throughout this section.
5.0-beta1 is a special case because it's a beta release; we want to test
against it but it's a beta so it doesn't make sense to replace 4.0 with it
(yet). It does make sense to replace 4.0 with 4.1; then, once 5.0 comes out of
beta we can replace 4.1 with 5.0.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
