Uploaded image for project: 'OpenShift Service Mesh'
  1. OpenShift Service Mesh
  2. OSSM-3035

Design/Draft service mesh's release notes & feature status page

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Duplicate
    • Icon: Major Major
    • OSSM 3.0-TP2
    • None
    • Documentation
    • None
    • False
    • None
    • False

      The release notes page of OpenShift Service Mesh format is from a while back, and hasn't kept up with other formatting changes. Some aspects of it are confusing, and it could use a clean up and reformatting. It is difficult to understand the support status across features.

      Serverless's release note page could be used as a potential example: https://docs.openshift.com/container-platform/4.6/serverless/serverless-release-notes.html#serverless-tech-preview-features_serverless-release-notes

      OpenShift's Release notes page could be another example: https://docs.openshift.com/container-platform/4.10/release_notes/ocp-4-10-release-notes.html#ocp-4-10-technology-preview

      Some potential changes to make:

      • Move the "core features" section to the "About OpenShift Service Mesh" page, as these are not release notes. This heading also doesn't make sense for the other release notes.
      • The sections following the release notes (Technology Preview, Deprecated and removed features, Known issues, fixed issues) should be on a per-release basis rather than a single section that needs to be updated after each release. This would be consistent with the serverless page above. As a customer may be on any given release, it's better to capture a snapshot of each release than to have a single section that needs to be kept up to date and may only be relevant for the latest release.
        • This could also be implemented as a table of features as in the OCP docs section - in general, users shouldn't have to search around to know if a feature is supported or not, so a table could make sense.
      • Do we need sections for Distributed Tracing still?

      These changes should be made pragmatically for future releases - ie do not go and re-write the release notes from all previous releases, though we should position ourselves to use a more consistent format for future releases (similar to serverless).

              Unassigned Unassigned
              jlongmui@redhat.com Jamie Longmuir
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: