docs(self-managed): update helm version matrix

[aabouzaid]

Description

As we release the alpha Helm charts publically, I've added the version matrix links for those charts.

Also, I added it to previous Camunda docs from 8.3-8.5

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support. (add bug or support label)
• This is already available but undocumented and should be released within a week. (add available & undocumented label)
• This is on a specific schedule and the assignee will coordinate a release with the DevEx team. (create draft PR and/or add hold label)
• This is part of a scheduled alpha or minor. (add alpha or minor label)
• There is no urgency with this change (add low prio label)

PR Checklist

• My changes are for an upcoming minor release and:
  • are in the /docs directory (version 8.8).
  • are in the /versioned_docs/version-8.7/ directory (version 8.7).
• My changes are for an already released minor and are in a /versioned_docs directory.

• I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
  • Engineering team review
  • Technical writer review via @camunda/tech-writers unless working with an embedded writer.

[conceptualshark]

I'm hesitant to include versions higher than the docs version (for example, if you're on 8.5, you should only see the matrix for 8.5 and lower) - it means there's more to remember and keep accurate at future releases. Is this something that is helpful to have documented in this way? @akeller Do you have any opinions on how much to document here?

[akeller]

I'm hesitant to include versions higher than the docs version (for example, if you're on 8.5, you should only see the matrix for 8.5 and lower) - it means there's more to remember and keep accurate at future releases. Is this something that is helpful to have documented in this way? @akeller Do you have any opinions on how much to document here?

I agree with you @conceptualshark. Unless there is a reason you need to see this info for higher versions, let's keep changes to anything current version and lower.

[aabouzaid]

it means there's more to remember and keep accurate at future releases

I believe it's the same. We need to go through all releases and remove the unsupported version for each one.

So when 8.7 is released, we need to go to all versions and remove 8.3
Which is even more work than copying and pasting the same content for all versions.

I'd say either we include the info for the current version or make all versions have the same content instead of having them.

@conceptualshark @akeller, what do you think?

[akeller]

@conceptualshark @akeller, what do you think?

We already remove/add info to the supported environment page for each minor version, so I don't see any differences there. If you don't want to have to deal with removing it manually for the minor, we can add that to our release manager checklist so you and your team just need to review it.

[aabouzaid]

@akeller If I got your comment correctly, I just added the info for the corresponding Camunda release, as we do in all other parts of the docs.

[github-actions]

The preview environment relating to the commit 308049b has successfully been deployed. You can access it at https://preview.docs.camunda.cloud/pr-5266/index.html

[akeller]

@aabouzaid I added the deploy label because I'm wondering if we are not understanding each other.

Do we need to add the helm version matrix to the component version table? Or should we not have the helm version as a matrix/table at all? If there is one version of the helm chart for one minor version, we probably don't need a table. I'm having trouble seeing what the best way is to present this information based on the conversation.

[aabouzaid]

@akeller That makes sense. Should I remove the table then and make a normal format?

[conceptualshark]

Do we need to add the helm version matrix to the component version table? Or should we not have the helm version as a matrix/table at all? If there is one version of the helm chart for one minor version, we probably don't need a table. I'm having trouble seeing what the best way is to present this information based on the conversation.

We'd thought add it to the component version table, but I didn't want to make this table more unwieldy at the time, and it seemed more logical to find in the Self-Managed section.

We do use a lot of "see the Helm version matrix to determine x y z" in the docs, but I don't know how often needing to know versions outside of the one you're on is necessary (outside of upgrading)? So maybe just having the single version match the docs version/product version is fine here.