Release catchup

.gitignore

@@ -1,2 +1,4 @@
 .DS_Store
 public
+
+*.swp

CONTRIBUTING.md

@@ -5,8 +5,10 @@ This file refers to the process of contributing to this documentation repository
 
 ## Repository Structure
 1. Each branch covers some form of release of the software
-    - The `latest` and `beta` branches cover the unstable features in development / early testing 
-    - The `X.Y` versioned branches track major and minor stable releases
+    - The `latest` branch covers the unstable features in development / early testing
+    - The `stable` and `X.Y` versioned branches track major and minor stable releases
+      - `stable` documents the current latest stable version
+      - It only branches into the corresponding numbered branch at the time of the next version number increment
     - Patch release (`X.Y.Z`) changes are documented (as relevant) in the corresponding minor release branch (`X.Y`)
 1. Documentation content is in the `content` directory
 1. The theme is included in the `themes` directory, as a git submodule
@@ -18,9 +20,7 @@ This file refers to the process of contributing to this documentation repository
     - It is recommended that software pull requests that change an interface or part of the documented code structure be marked with a `docs-needed` [label](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels), and include a comment about which aspects need to be documented prior to the feature being merged (while the details are still front of mind for the developer)
     - If a software pull request is labelled as `docs-needed`, once a corresponding documentation pull request is merged the feature PR can be re-labelled with a completion status (e.g. `docs-minimal` or `docs-complete`)
     - Beta releases may require that no merged features are labelled with `docs-needed`, and stable releases may require that no included features are labelled with `docs-needed` or `docs-minimal`
-1. When a new beta release of the software is made, the relevant changes in the `latest` branch get merged or cherry-picked over to the `beta` branch
-    - This is handled by the documentation maintainers
-1. When a new major or minor stable release of the software is made, the `beta` branch gets duplicated into a new branch tracking that version, which then gets reconfigured with a fixed release number
+1. When a new major or minor stable release of the software is made, the `stable` branch gets duplicated into a new branch tracking that version, which then gets reconfigured with a fixed release number, and the now-stable features in the `latest` branch get cherry-picked to the `stable` branch
     - This is handled by the documentation maintainers
 
 # Making a Contribution
@@ -65,7 +65,7 @@ Specific processes are covered below, but the general process is:
 ### Improving/Adding Documentation for Released Features
 > 💡 Relevant features can typically be found by looking through the public documentation for features with minimal information, and/or [searching this repository](https://github.com/bluerobotics/Cockpit-docs/issues?q=is%3Aissue+is%3Aopen+label%3Acontent) for issues with the `content` label, or [searching the software repository](https://github.com/bluerobotics/Cockpit/issues?q=is%3Apull+is%3Aclosed+label%3Adocs-minimal) for pull requests with the `docs-minimal` label.
 
-Documentation for existing features should generally first be [added to the `latest` branch](#documenting-a-newupcoming-feature), before optionally being backported to the `beta` and/or any relevant version branches, usually via [`git cherry-pick`](https://git-scm.com/docs/git-cherry-pick).
+Documentation for existing features should generally first be [added to the `latest` branch](#documenting-a-newupcoming-feature), before optionally being backported to the `stable` and/or any relevant version branches, usually via [`git cherry-pick`](https://git-scm.com/docs/git-cherry-pick).
 
 If your changes were requested in an Issue, make sure to include "Resolves #{ISSUE-NUMBER}" in the description of your pull request, to link to and automatically close the Issue when the pull request is merged.
 

README.md

@@ -2,22 +2,23 @@
 
 This repository documents the Blue Robotics' [Cockpit](https://blueos.cloud/cockpit/docs/usage/overview) software.
 
-The documentation is generated using the [Zola](https://www.getzola.org/) static site generator.
+The documentation is generated using the [Zola](https://www.getzola.org/) static site generator, together with [BlueTheme](https://github.com/bluerobotics/bluetheme).
 
 ## Structure
 
 - Each branch covers a minor release (`X.y`) of the software, including any patches (`X.Y.z`) of that release
-    - The `latest` branch covers the development state in the BlueOS `master` branch, but is not expected to be consistently up to date
-    - The `beta` branch covers the latest beta release, and is intended to at least minimally describe all included features
+    - The `latest` branch covers the development state in the Cockpit `master` branch, but is not expected to be consistently up to date
+        - It is intended to at least minimally describe all included features in the latest available beta release
+    - The `stable` branch covers the latest stable version, and is intended to sufficiently describe all included features
 - For ease of contribution, and to keep the search index independent between versions, each branch is built independently
 - Documentation content is in the `content` directory
 - The theme is provided as a submodule in the `themes` directory
 
 ## Contributing
 
-New features should first be documented in `latest`, and subsequently branched into `beta` and a stable version toegther with the software release cycle.
+New features should first be documented in `latest`, then cherry-picked into `stable` as part of the software release cycle.
 
-Improved documentation for existing features should at least be added to `latest`, and ideally also cherry-picked into the existing `beta` and stable-versioned branches as relevant.
+Improved documentation for existing features should at least be added to `latest`, and ideally also cherry-picked into the existing `stable` and numbered stable version branches as relevant.
 
 Detailed contribution information can be found in [CONTRIBUTING.md](CONTRIBUTING.md)