[
https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711061#comment-17711061
]
Michael Semb Wever edited comment on CASSANDRA-17869 at 4/11/23 5:05 PM:
-------------------------------------------------------------------------
bq. As then every time we move forward with branches and JDK versions we need
to modify the lower/upper bound for upgrading in each test. And considering we
keep on adding more tests, it sounds more time consuming and easy to forget...
We won't forget if we put in asserts. That way it must be done when
branching/bumping the version. IMHO this is a good start, and will ensure
things move in the right direction, without the need of a jira ticket (that is
usually only on the reporter's radar and otherwise all too easily forgotten).
I've added such an assert to dtests here:
https://github.com/apache/cassandra-dtest/commit/824c90c4d8b606d3beffc57f99c666d41828bca8#diff-16fb32b744845ae88f5f9638516d36b89d7ff14b2215779c3dc8959e567c8ab2R262
bq. confusing when reading tests why we have mentioned start versions for paths
we will not support upgrades at all.
parameter names are a bit overloaded.
they could be:
{code}
upgradesToCurrentFrom(startingFrom)
upgradesTo(startingFrom, to)
upgradesFrom(from, endingTo)
upgrades(startingFrom, endingTo)
{code}
That is, "from" and "to" are fixed edges, while startingFrom and endingTo are
bounds applied against the matrix of supported upgrade paths.
bq. upper bound of a version to upgrade to should be changed on branching new
major
this is not needed. all non-supported upgrade paths are excluded, and if a test
ends up with no upgrade paths at all it will fail.
was (Author: michaelsembwever):
bq. As then every time we move forward with branches and JDK versions we need
to modify the lower/upper bound for upgrading in each test. And considering we
keep on adding more tests, it sounds more time consuming and easy to forget...
We won't forget if we put in asserts. That way it must be done when
branching/bumping the version.
I've added such an assert to dtests here:
https://github.com/apache/cassandra-dtest/commit/824c90c4d8b606d3beffc57f99c666d41828bca8#diff-16fb32b744845ae88f5f9638516d36b89d7ff14b2215779c3dc8959e567c8ab2R262
bq. confusing when reading tests why we have mentioned start versions for paths
we will not support upgrades at all.
parameter names are a bit overloaded.
they could be:
{code}
upgradesToCurrentFrom(startingFrom)
upgradesTo(startingFrom, to)
upgradesFrom(from, endingTo)
upgrades(startingFrom, endingTo)
{code}
That is, "from" and "to" are fixed edges, while startingFrom and endingTo are
bounds applied against the matrix of supported upgrade paths.
bq. upper bound of a version to upgrade to should be changed on branching new
major
this is not needed. all non-supported upgrade paths are excluded, and if a test
ends up with no upgrade paths at all it will fail.
> 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: [email protected]
For additional commands, e-mail: [email protected]
