Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Produce release artifacts for support matrix #5316

Open
devinrsmith opened this issue Apr 2, 2024 · 1 comment
Open

Produce release artifacts for support matrix #5316

devinrsmith opened this issue Apr 2, 2024 · 1 comment
Labels
feature request New feature or request triage
Milestone

Comments

@devinrsmith
Copy link
Member

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:

[11, 17, 21]

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

@devinrsmith
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request triage
Projects
None yet
Development

No branches or pull requests

1 participant