From 57420677e511300bc6eebb6c18726ec5b623c29b Mon Sep 17 00:00:00 2001 From: ES-Alexander Date: Thu, 19 Dec 2024 22:46:31 +1100 Subject: [PATCH] CONTRIBUTING: reflect in-use project structure --- CONTRIBUTING.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 63204f0..d7dcf3e 100644 --- a/CONTRIBUTING.md +++ b/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.