Merge branch 'main' into adr/oidc

modules/ROOT/nav.adoc

@@ -1,3 +1,3 @@
 * xref:quickstart.adoc[]
 * xref:kubernetes.adoc[]
-* xref:getting_started.adoc[]
+* xref:getting-started.adoc[]

modules/ROOT/nav2.adoc

@@ -1,5 +1,6 @@
 // This second nav file is for another menu entry at the end of the navigation menu
 // see: https://docs.antora.org/antora/3.0/navigation/organize-files/#multiple-files-per-module
-* xref:release_notes.adoc[Release Notes]
+* xref:release-notes.adoc[Release notes]
 * xref:product-information.adoc[]
+* xref:policies.adoc[]
 * xref:licenses.adoc[Licenses]

modules/ROOT/pages/getting_started.adoc → modules/ROOT/pages/getting-started.adoc

@@ -1,4 +1,5 @@
 = Getting Started
+:page-aliases: getting_started.adoc
 
 One of the best ways of getting started with a new platform is to try it out. Any big data platform has a lot of moving parts and getting some hands on keyboard time with it helps reinforce learning.
 

modules/ROOT/pages/policies.adoc

@@ -1,12 +1,11 @@
-= Lifecycle Policies
+= Lifecycle policies
 
-This page details our current lifecycle policies around various parts of our product - the Stackable Data Platform (SDP).
+This page details our lifecycle policies around various parts of our product - the Stackable Data Platform (SDP).
 
-We define multiple lifecycle policies for different parts of our platform, but all these policies follow some common goals:
+We define multiple lifecycle policies for different parts of our platform, but all policies follow some common goals:
 
 * It should always be possible to upgrade to a new version of SDP without also changing any of your Kubernetes resources as long as you are not currently using anything that has already been marked as deprecated
 ** This means you can upgrade the control plane independently of the user-facing products
-
 * All deprecations follow a predictable lifecycle that allows planning of upgrades ahead of time
 
 The guarantees we give are on multiple levels as detailed below:
@@ -20,21 +19,20 @@ All these policies may evolve as we learn what works best for our customers and
 
 These policies are from *July 2023*.
 
-
-== Stackable Data Platform Lifecycle Policy
+== Stackable Data Platform lifecycle policy
 
 NOTE: This policy concerns releases of our platform as a whole and how long and to which extent we support each version.
 
 We do releases of our Stackable Data Platform.
 These releases get a name based on the year and month they have been released in (e.g. `23.4`, `23.7`, also called https://calver.org/[CalVer]). This name does not follow Semantic Versioning (https://semver.org/[SemVer]). We may release patches for a release, which then follow the PATCH naming semantics of SemVer (e.g. `23.4.1`) or the _Micro_ name from CalVer. See below for our policy on patches for the SDP.
 
-We do support an SDP release for a specific time after its release.
+We support an SDP release for a specific amount of time after its initial release.
 
 An SDP release contains our operators and other code developed at Stackable as well as the product docker images.
 
 TIP: Our policy is inspired by the https://kubernetes.io/releases/patch-releases/[Kubernetes] and the https://access.redhat.com/support/policy/updates/openshift#ocp4[OpenShift] policies.
 
-=== Full Support Phase
+=== Full support phase
 
 This phase begins once a new non-patch SDP version is released and ends after a 6-month period OR 3 months after the general availability of the superseding non-patch release, whichever is later.
 
@@ -47,26 +45,26 @@ image:full_support_scenario_2.png[Full Support Scenario 2]
 We _will_ release new patch releases of a SDP release (e.g. `23.4.1`) for any issues we deem Critical or High (see definition below) once fixes become available.
 We _may_ release new patch releases for other reasons.
 
-=== Maintenance Phase
+=== Maintenance phase
 
 This phase commences after the _Full Support_ phase for the respective SDP version and ends 12 months after general availability of the SDP release.
 
 We _may_ release new patch releases of a SDP release (e.g. `23.4.1`) for any issues we deem Critical or High (see definition below) once fixes become available.
+We may release patches for other reasons.
 
 image:maintenance_phase.png[Maintenance Phase]
 
-=== General
-
-We may release patches for other reasons.
+== Upgrade policy
 
 Customers are expected to upgrade their SDP environment to the most current supported patch/micro (`23.4.z`) version.
-Make sure to follow our release notes to learn of valid upgrade paths, some intermediate updates might be necessary.
+Skipping SDP releases while upgrading is currently not supported.
+The only upgrade path we support is from one version to the next.
 
-== CRD Versioning Lifecycle Policy
+== CRD Versioning lifecycle policy
 
 IMPORTANT: As of June 2023 all our CRDs are versioned as `alpha1`. We will start introducing other versions later in 2023.
 
-``CustomResourceDefinition``s at Stackable are versioned.
+CustomResourceDefinitions at Stackable are versioned.
 
 Our policies around CRD versioning are inspired by the https://kubernetes.io/docs/reference/using-api/deprecation-policy/[Kubernetes Deprecation Policy].
 
@@ -90,7 +88,7 @@ Similar to the Exception noted by the Kubernetes project itself, we will also ev
 NOTE: According to these rules it is legal to _add_ fields to a CRD without increasing the version as long as there is a default for this field.
 
 
-== Product Lifecycle Policy
+== Product lifecycle policy
 
 SDP ships with a lot of different downstream products (e.g. Apache HBase, Apache Superset).
 
@@ -114,9 +112,10 @@ image:product_release_cycle.png[Product Lifecycle Policy]
 === Deprecation
 
 Every product version that gets removed will be deprecated for at least 1 SDP release before removal.
-This guarantees that users can update the operators (e.g. from 23.1 to 23.4) without the need to simultaneously update the product version as well. The flow is to first update the control plane (the operators) and afterward the product versions if desired (e.g. when the currently used version is now deprecated).
+This guarantees that users can update the operators (e.g. from 23.1 to 23.4) without the need to simultaneously update the product version as well.
+The flow is to first update the control plane (the operators) and afterward the product versions if desired (e.g. when the currently used version is now deprecated).
 
-=== Definition of "support"
+=== Definition of support
 
 We will ship new versions of the LTS release line in our currently supported SDP releases (see above) for any issues we deem Critical or High in severity when they become available.
 
@@ -127,17 +126,19 @@ It is our explicit goal to limit the amount of times we have to ship a version o
 We may ship new versions for existing SDP releases for other issues as well.
 
 
-== OpenShift & Kubernetes Support Policy
+== OpenShift & Kubernetes support policy
 
 For every SDP release we will publish a list of supported Kubernetes versions.
 
 We are aiming to support the last three Kubernetes versions but will make case-by-case decisions by taking into account the currently supported Kubernetes versions.
 We will also take into account currently supported OpenShift versions as published by RedHat. It is our goal to support all versions that are in Full or Maintenance support. As the releases may be overlapping we might not always support the latest Kubernetes or OpenShift versions when we release a SDP version.
 
 
-== Support Policy (Security & Bugs)
+== Support policy (security & bugs)
 
-Stackable will analyze published security vulnerabilities (e.g. CVEs but other sources may apply as well) for all the products we support as well components developed by us and their dependencies. We take various sources into account when assigning a criticality. Among those sources is the NVD database, but we place higher value on the self-assessments by the projects themselves, and we will additionally evaluate vulnerabilities in the context of how they are used in the Stackable Data Platform.
+Stackable will analyze published security vulnerabilities (e.g. CVEs but other sources may apply as well) for all the products we support as well components developed by us and their dependencies.
+We take various sources into account when assigning a criticality.
+Among those sources is the NVD database, but we place higher value on the self-assessments by the projects themselves, and we will additionally evaluate vulnerabilities in the context of how they are used in the Stackable Data Platform.
 
 We will then assign a criticality to each vulnerability according to similar rating categories that https://access.redhat.com/security/updates/classification[RedHat has established]:
 

modules/ROOT/pages/release_notes.adoc → modules/ROOT/pages/release-notes.adoc

@@ -1,4 +1,5 @@
 = Release notes for the Stackable Data Platform
+:page-aliases: release_notes.adoc
 
 The Stackable platform consists of multiple operators that work together. Periodically a platform release is made,
 including all components of the platform at a specific version.

supplemental-ui/partials/navbar.hbs

@@ -1,12 +1,12 @@
 <a class="navbar-sub-item" href="{{{ relativize (versioned "home" page "index.html") }}}">Home</a>
 <a class="navbar-sub-item" href="{{{ relativize (versioned "home" page "/getting_started.html") }}}">Getting Started</a>
-<a class="navbar-sub-item" href="{{{ relativize (versioned "home" page "concepts/index.html") }}}">Concepts</a>
-<a class="navbar-sub-item" href="{{{ relativize (versioned "home" page "demos/index.html") }}}">Demos</a>
 <div class="navbar-sub-item drop-down">
-    Management
+    Platform
     <div class="drop-down-content">
-        <a class="drop-down-item" href="{{{ relativize (versioned "management" page "cockpit/index.html") }}}">Cockpit</a>
-        <a class="drop-down-item" href="{{{ relativize (versioned "management" page "stackablectl/index.html") }}}">stackablectl</a>
+        <a class="drop-down-item" href="{{{ relativize (versioned "home" page "concepts/index.html") }}}">Concepts</a>
+        <a class="drop-down-item" href="{{{ relativize (versioned "home" page "demos/index.html") }}}">Demos</a>
+        <a class="drop-down-item" href="{{{ relativize (versioned "home" page "tutorials/index.html") }}}">Tutorials</a>
+        <a class="drop-down-item" href="{{{ relativize (versioned "home" page "release-notes.html") }}}">Release Notes</a>
     </div>
 </div>
 <div class="navbar-sub-item drop-down">
@@ -30,4 +30,21 @@
         <a class="drop-down-item" href="{{{ relativize (versioned "home" page "listener-operator/index.html") }}}">Listener</a>
     </div>
 </div>
+<div class="navbar-sub-item drop-down">
+    Management
+    <div class="drop-down-content">
+        <a class="drop-down-item" href="{{{ relativize (versioned "management" page "cockpit/index.html") }}}">Cockpit</a>
+        <a class="drop-down-item" href="{{{ relativize (versioned "management" page "stackablectl/index.html") }}}">stackablectl</a>
+    </div>
+</div>
+<div class="navbar-sub-item drop-down">
+    Policies and Licenses
+    <div class="drop-down-content">
+        <!-- TODO fix link to stable after next release (23.11) -->
+        <a class="drop-down-item" href="{{{ relativize "/home/nightly/product-information.html" }}}">Product Information</a>
+        <a class="drop-down-item" href="{{{ relativize (versioned "home" page "policies.html") }}}">Policies</a>
+        <!-- TODO fix link to stable after next release (23.11) -->
+        <a class="drop-down-item" href="{{{ relativize "/home/nightly/licenses.html" }}}">Licenses</a>
+    </div>
+</div>
 <a class="navbar-sub-item" href="{{{ relativize (versioned "home" page "contributor/index.html") }}}">Contribute</a>