You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of efforts to more thoroughly detail and document our support matrix, it would be a good idea to have an official release artifact as a source-of-truth for support-matrix information.
This likely spans a wide variety of artifacts (deephaven native application, deephaven-server [python], deephaven-core [python], pydeephaven [python], etc).
As the simplest support matrix, we might claim claim Java 11, 17, and 21 support. There is complexity that arises as we may or may not want to back this up with specific testing information; but then of course, the testing runs are with very specific versions of Java on specific hardware. It probably makes sense to capture both forms of data: we aspirationally support Java 11, 17, and 21 (across any "supported" system), and we've specifically done tests with Java version XYZ on hardware ABC.
As far as an aspiration support matrix for java is concerned, this is probably the easiest release artifact to deliver:
I don't think this is the actual filename we should necessarily produce, nor necessarily the structuring we should provide around it (just used as the simplest example). There's probably some collaboration between producing these support matrix artifacts and how the documentation team could consume them - whether it's a file-per-artifact, or a single support matrix file, etc.
It might be nice to capture the high-level support matrix as part of the application artifact itself; something in the jar that could easily be queried at runtime. We could also have a script to display this information, bin/support-matrix or something similar.
As part of efforts to more thoroughly detail and document our support matrix, it would be a good idea to have an official release artifact as a source-of-truth for support-matrix information.
This likely spans a wide variety of artifacts (deephaven native application, deephaven-server [python], deephaven-core [python], pydeephaven [python], etc).
As the simplest support matrix, we might claim claim Java 11, 17, and 21 support. There is complexity that arises as we may or may not want to back this up with specific testing information; but then of course, the testing runs are with very specific versions of Java on specific hardware. It probably makes sense to capture both forms of data: we aspirationally support Java 11, 17, and 21 (across any "supported" system), and we've specifically done tests with Java version XYZ on hardware ABC.
As far as an aspiration support matrix for java is concerned, this is probably the easiest release artifact to deliver:
support-matrix.java.json
:This could be sourced from https://github.com/deephaven/deephaven-core/blob/v0.33.3/.github/workflows/nightly-check-ci.yml#L18 (and as of #5313, our 0.34.0 release could claim
[11, 17, 21, 22]
).I don't think this is the actual filename we should necessarily produce, nor necessarily the structuring we should provide around it (just used as the simplest example). There's probably some collaboration between producing these support matrix artifacts and how the documentation team could consume them - whether it's a file-per-artifact, or a single support matrix file, etc.
Somewhat related to #3725
The text was updated successfully, but these errors were encountered: