[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710988#comment-17710988
]
Michael Semb Wever edited comment on CASSANDRA-17869 at 4/11/23 2:41 PM:
-------------------------------------------------------------------------
bq. It explicitly has a call to .upgradesToCurrentFrom(v3X) so it seems the
current matrix correctly ignores this call when it sees JDK which is not
supported by the respective Cassandra version we are trying to build. But I am
thinking we should probably change the method upgradesToCurrentFrom(version) to
maybe upgradesToCurrent() or so? And document that the versions we upgrade from
are detected based on the JDK version supported or so? Otherwise it looks
confusing at the moment.
Some tests have valid reason to explicitly define the upgrade path.
upgradesToCurrentFrom(_) makes sense as it is intentionally from an explicit
minimum version.
The apidocs are:
{noformat}
/** performs all supported upgrade paths that exist in between from and
CURRENT (inclusive) **/
public TestCase upgradesToCurrentFrom(Semver from) {…}
/**
* performs all supported upgrade paths to the "to" target; example
* {@code upgradesTo(3.0, 4.0); // produces: 3.0 -> 4.0, 3.11 -> 4.0}
*/
public TestCase upgradesTo(Semver from, Semver to) {…}
/**
* performs all supported upgrade paths from the "from" target; example
* {@code upgradesFrom(4.0, 4.2); // produces: 4.0 -> 4.1, 4.0 -> 4.2}
*/
public TestCase upgradesFrom(Semver from, Semver to) {…}
/**
* performs all supported upgrade paths that exist in between from and
to that include the current version.
* This call is equivilent to calling {@code upgradesTo(from,
CURRENT).upgradesFrom(CURRENT, to)}.
**/
public TestCase upgrades(Semver from, Semver to) {…}
/** Will test this specific upgrade path **/
public TestCase singleUpgradeToCurrentFrom(Semver from) {…}
{noformat}
But we do have the overhead of when {{CURRENT}} changes (replaced with a
specific version, e.g. {{v50X}}) we then need to scan the tests and fix it. The
same problem exists in dtest-upgrades.
We could add an assert in these methods to prevent illegal (unsupported)
upgrade paths.
The method does not need to change name, but all such calls should be replaced
with `{{. upgrades(V3X, V41X)}}`
was (Author: michaelsembwever):
bq. It explicitly has a call to .upgradesToCurrentFrom(v3X) so it seems the
current matrix correctly ignores this call when it sees JDK which is not
supported by the respective Cassandra version we are trying to build. But I am
thinking we should probably change the method upgradesToCurrentFrom(version) to
maybe upgradesToCurrent() or so? And document that the versions we upgrade from
are detected based on the JDK version supported or so? Otherwise it looks
confusing at the moment.
Some tests have valid reason to explicitly define the upgrade path.
upgradesToCurrentFrom(_) makes sense as it is intentionally from an explicit
version.
The apidocs are:
{noformat}
/** performs all supported upgrade paths that exist in between from and
CURRENT (inclusive) **/
public TestCase upgradesToCurrentFrom(Semver from) {…}
/**
* performs all supported upgrade paths to the "to" target; example
* {@code upgradesTo(3.0, 4.0); // produces: 3.0 -> 4.0, 3.11 -> 4.0}
*/
public TestCase upgradesTo(Semver from, Semver to) {…}
/**
* performs all supported upgrade paths from the "from" target; example
* {@code upgradesFrom(4.0, 4.2); // produces: 4.0 -> 4.1, 4.0 -> 4.2}
*/
public TestCase upgradesFrom(Semver from, Semver to) {…}
/**
* performs all supported upgrade paths that exist in between from and
to that include the current version.
* This call is equivilent to calling {@code upgradesTo(from,
CURRENT).upgradesFrom(CURRENT, to)}.
**/
public TestCase upgrades(Semver from, Semver to) {…}
/** Will test this specific upgrade path **/
public TestCase singleUpgradeToCurrentFrom(Semver from) {…}
{noformat}
But we do have the overhead of when {{CURRENT}} changes (replaced with a
specific version, e.g. {{v50X}}) we then need to scan the tests and fix it. The
same problem exists in dtest-upgrades.
We could add an assert in these methods to prevent illegal (unsupported)
upgrade paths.
The method does not need to change name, but all such calls should be replaced
with `{{. upgrades(V3X, V41X)}}`
> Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on
> jenkins agents
> ------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17869
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17869
> Project: Cassandra
> Issue Type: Task
> Components: Build
> Reporter: Michael Semb Wever
> Assignee: Michael Semb Wever
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add JDK17 option to cassandra-builds build-scripts, they only currently
> support options {{8}} and {{11}}.
> Add JDK17 to the matrix axes in the jenkins dsl.
> Ensure JDK17 is installed on all the jenkins agents.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
