Simple test support chart

[jarmak-nv]

Overview

This PR creates a new page on doc.rapids.ai for version support. To support our users, we need a singular location where people can always go to see what we currently support, and should they need something that is no longer supported, which version of RAPIDS best fits their needs.

https://docs.rapids.ai/version-support is currently its future home based on this PR.

Changes

Right now, the timelines are simple alpine visualizations. This is primarily because I used the selector as a starting point and didn't want to have to install any new items. Its possible we want to use alpine functionality, but it's ultimately unimportant what we end up with.

The important part is we land on a way to clearly communicate:

• What is supported
• When it will no longer be supported
• Historically what was supported in past releases

Drivers

I've added in driver version with the intention of resolving #415 with this PR. We can update repo/docs language to point to this location to see current supported driver/cuda vers.

[netlify]

✅ Deploy Preview for docs-rapids-ai ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	139c417
🔍 Latest deploy log	https://app.netlify.com/sites/docs-rapids-ai/deploys/65a8175a3a6dbf00080938e4
😎 Deploy Preview	https://deploy-preview-466--docs-rapids-ai.netlify.app/version-support
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jarmak-nv]

@aravenel @taureandyernv @raydouglass @bdice @ajschmidt8

Tagging some people I know might have thoughts on this - please tag others as well. I'm entirely unmarried to the implementation here, so I'm very open to changes on that.

Additionally, the content is currently wrong/made up in the timeline bars. I figured this will take some iteration and will look forward/backward when we're more settled on an approach.

[bdice]

Style

Here's my very favorite website to consult when dealing with version support: https://endoflife.date/python

I vote to keep this tabular, like what's in that website. The Gantt chart is really cute but ultimately it is not necessary to achieve our goals of providing documentation. Unless you know how to automate the chart creation, I don't want us to maintain code like margin-left: 20%; width: 50%; for every row, especially if it doesn't track with real-time dates automatically. Even the nice chart in https://scientific-python.org/specs/spec-0000/ is SVG generated by Python, which requires regular re-runs to update. Let's avoid that.

Content

Does "Current" and "Upcoming" map to 23.12 / 24.02? Or would this timeline go even wider (plans for 24.04, ...)? If we adopt a tabular form, there is a clearer way to distinguish this. We would have a table for every release (future, present, past) that lists the supported versions of Python, CUDA, etc. Using a table like this also inverts the problem: rather than telling readers which RAPIDS releases support Python 3.10, I would prefer for us to answer which Python versions are supported by RAPIDS 23.12.

Do we also need to communicate support for the RAPIDS release itself? If I were to browse to a page that said "version support", I think I would expect to see dates for when 23.12 will be supported (and dropped). Presumably this ties in closely with NVAIE and other efforts, but perhaps with a shorter OSS release lifetime (we typically hotfix only the most recent release, sometimes two releases).

The pillars of our support matrix are:

• CUDA runtime version
• Python version support
• OS version support (Ubuntu 22.04, ...)
• CUDA driver version
• Arch support (x86-64, ARM)

Concretely, the things I want to track here are CUDA runtime version support and Python version support.

OS version support would be a third possibility but we rarely have timelines that we control. I think this would be hard to document properly over time (dropping/adding Ubuntu versions is usually not tied to any specific timeline from Ubuntu itself or NVIDIA, as far as I know). OS support feels like it's more of a detail of what we cover in CI workflows. That comes down to the supported glibc versions at build time and "whatever we can test is what we officially support" at test time.

I don't want to track drivers here, or in RAPIDS docs (or repositories) at all. I want to move away from that and say things like "RAPIDS requires a CUDA driver that is compatible with your CUDA runtime version." I would prefer to link out to resources like https://docs.nvidia.com/deploy/cuda-compatibility/ so we aren't maintaining a mapping in RAPIDS that is better documented by CUDA itself.

Maybe just list the minimum currently supported driver versions for each major CUDA? IE >=470 for CUDA 11.x & >=525 for CUDA 12.x? We would still need to update these driver versions as they drop out of support (525 drops in December for example).

@raydouglass was on this track here but I would vote for an even more extreme version of driver-info-minimalism than his proposal.

Arch support is mostly at parity today between x86-64 and ARM, but there isn't always a timeline associated with that, so it probably doesn't fit here. Again, this is easier to document (and add caveats/notes) if we have a table of information for each RAPIDS release rather than a timeline for this "axis" of the support matrix.

[jarmak-nv]

Appreciate the feedback @bdice! Hoping to get more, but some thoughts:

• 100% I like a table view; it's easy/clean, happy to go with it
  • I don't think it would be particularly hard to automate the gantt bars though, if we have start dates and end dates, the rest is linear interpolation to get where the bars should be
• I would like to see us commit to support/end of life timelines far ahead, so yes the intention was the "upcoming" would reach as far as necessary to signal support
  • However, I do like the thought of "here's what we support for a given release"
  • I'm not certain which approach I like more - but in general I'm still leaning to a more far-looking output, both for our team's understanding, and our users. Right now the "when" of version changes isn't predictable and I would like to change that
• I think we need to include some level of driver support, I like @raydouglass's answer; while yes it duplicates some effort vs the CUDA support page, but also every external link reduces the likelihood that someone reads it and instead takes a less desirable path (giving up, asking on slack/stack, etc.)
• Agree on OS support, IMO we should not cover it here and leave what we already have inside of docs.rapids.ai/install as the place to look for OS info (tangent: I would love to get explicit windows non-support errors for us on installation attempts)
• Yeah Arch support is a good thing to bring up too; I'm still happy with it being relegated to docs.rapids.ai/install, but, I can also imagine a world where we merge both the timeline and your table suggestion and the timeline only tracks python/CUDA but the table tracks more things for a specific release. OTOH not trying to make a bucket of new work. Hence thinking aloud a bit! I agree arch support is really stable right now and not much of a confusion point for people aside from Jetson.