releases: defines the release workflow for PX4

* also introduces core concept list

en/SUMMARY.md

@@ -420,6 +420,7 @@
     - [Writing your First Application](modules/hello_sky.md)
     - [Application/Module Template](modules/module_template.md)
   - [Concepts](concept/index.md)
+    - [PX4 Core Components](concept/core_components.md)
     - [PX4 System Architecture](concept/px4_systems_architecture.md)
     - [PX4 Flight Stack Architecture](concept/architecture.md)
       - [Controller Diagrams](flight_stack/controller_diagrams.md)

en/concept/core_components.md

@@ -0,0 +1,66 @@
+# PX4 Core Components
+
+These core components define the core functionality of PX4-Autopilot. Thus whether they are functioning correctly is being constantly monitored by the Maintainers, as well as in Continuous Integration tests. These components are the first priority that should work in a stable point releases.
+
+## Core component criteria
+
+Each core component must have:
+- Maintainer
+- Tester
+
+## PX4 Core Components List
+
+For many of the core components that has a corresponding label in Github, you can click on them to view the relevant Issue/PRs.
+
+| Core component (category) | Sub component | Maintainer |
+|---|---|---|
+| [uORB (Architecture)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3AUorb+) |  |  |
+| [Parameter (Architecture)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3AParameter+) |  |  |
+| Realtime Clock (Architecture) |  |  |
+| Work queue (Architecture) |  |  |
+| GNSS (State Estimation) | Velocity / Position |  |  |
+|  | Heading |  |
+| [Optical flow (State Estimation)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Optical+flow+%F0%9F%91%81%EF%B8%8F%E2%80%8D%F0%9F%97%A8%EF%B8%8F%22) |  |  |
+| [Vision](https://github.com/PX4/PX4-Autopilot/issues?q=label%3Avision) (State Estimation) |  |  |
+| [Boards (NuttX)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Boards+%28flight+controller%29+%F0%9F%8D%AB%22+) | [Pixhawk standard](https://github.com/PX4/PX4-Autopilot/issues?q=label%3Apixhawk) |  |
+| IMU (Driver) |  |  |
+| Distance Sensor (Driver) |  |  |
+| Failure Injection (?) |  |  |
+| RTK GPS (Driver) | Heading estimate from dual RTK GPS | [Alex Klimaj](https://github.com/AlexKlimaj) |  |
+| [Documentation](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Documentation+%F0%9F%93%91%22) |  |  |
+| Battery (Library) |  |  |
+| Flight Task (Library) |  |  |
+| Matrix (Library) |  |  |
+| Autotuning (Library) |  |  |
+| [Github Actions (Continuous Integration)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22CI+%F0%9F%A4%96%22) |  |  |
+| [Jenkins (Continuous Integration)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3Ajenkins-ci) |  |  |
+| Linux (Toolchain) |  |  |
+| Mac OS (Toolchain) |  |  |
+| [Windows (Toolchain)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3Awindows) | WSL2 |  |  |
+| [ROS2](https://github.com/PX4/PX4-Autopilot/issues?q=label%3AROS2) |  |  |
+| [Gazebo Classic (Simulation)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22gazebo+classic%22) |  |  |
+| [Gazebo (Simulation)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3Agazebo) |  |  |
+| Flightgear (Simulation) |  |  |
+| JSBSim (Simulation) |  |  |
+| jMAVSim (Simulation) |  |  |
+| SIH (Simulation) |  |  |
+| Multivehicle Simulation |  |  |
+| [MAVLink (Communication)](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Communication+%28MAVLink%29+%F0%9F%93%A1%22) | | |
+
+### Vehicle types
+
+| Core component | Sub component | Maintainer |
+|---|---|---|
+| [Multirotor](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Multirotor+%F0%9F%9B%B8%22) | Acro mode |  |
+|  | Stabilized mode |  |
+|  |  |
+| [Fixed wing](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Fixed+Wing+%F0%9F%9B%A9%EF%B8%8F%22) |  |
+| [Hybrid VTOL](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Hybrid+VTOL+%F0%9F%9B%A9%EF%B8%8F%F0%9F%9A%81%22) |  |
+|  | Altitude mode in hover |
+|  | Position mode in hover |
+|  | Auto mode in hover |  |
+|  | Quad-chute |  |
+|  | Pull/Tilter assist for forward acceleration in hover |  |
+|  | Weather vane (automatically aligning vehicle heading into wind) |  |
+| [Boat](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Boat+%F0%9F%9A%A4%22) |  |  |
+| [Rover](https://github.com/PX4/PX4-Autopilot/issues?q=label%3A%22Rover+%F0%9F%9A%99%22) |  |  |

en/releases/index.md

@@ -1,6 +1,8 @@
 # Releases
 
-A list of PX4 release notes, they contain a list of the changes that went into each release, explaining the included features, bug fixes, deprecations and updates in detail.
+## Release Notes
+
+The release notes archive for each release contains a detailed list of included features, bug fixes, deprecations, and updates.
 
 - [main](../releases/main.md) (changes since v1.15)
 - [v1.15](../releases/1.15.md)
@@ -9,3 +11,100 @@ A list of PX4 release notes, they contain a list of the changes that went into e
 - [v1.12](../releases/1.12.md)
 
 The full archive of releases for the PX4 autopilot project can be found on [GitHub](https://github.com/PX4/PX4-Autopilot/releases)
+
+## Release Versioning
+
+The PX4 project is using a versioning scheme based on Semantic versioning system ([Wikipedia article](https://en.wikipedia.org/wiki/Software_versioning)). The current scheme is as follows:
+
+```sh
+   Major.minor.patch[-beta#]
+```
+
+:::note
+Full semantic versioning will be adopted starting from `v2.0.0`. The releases before that didn't follow the strict Semantic versioning process. Before `v2.0` it is assumed bumps in `minor` are considered as `Major` releases.
+:::
+
+- Change in `Major`: Breaking changes in functionality
+- Change in `minor`: New non-breaking changes and features
+- Change in `patch`: All other non-breaking changes including bugfixes
+
+## Release Schedule
+
+PX4 follows the following release schedule:
+
+- `Major` or `minor` releases: Roughly every 6 months
+- `patch` releases: When critical bug-fix / hardware support is needed
+- `beta` releases: Every 1 week during beta testing phase
+
+## Stakeholders
+
+The whole process depends on the contribution of the Maintainers. However, for the release process specifically, a 'Release manager' (referred below as well) will be the person in charge of overseeing the overall process.
+
+## Release Procedure
+
+The decision on whether the upcoming release will involve a change in major version, or just a minor will be discussed during the [weekly coordination meeting](../contribute/dev_call.md).
+
+If the general consensus agrees that the change for the upcoming release is big enough, the major version will be updated. Otherwise, only the minor version will be updated.
+
+### New Major Release
+
+The process starts when the release manager creates a new branch following the `release/Major.minor` pattern, this new branch is based out of work from the `main` branch of the PX4-Autopilot project on GitHub.
+
+For the initial beta release of a new major/minor change, a "branch out deadline" gets set during the weekly call.
+
+The procedure is:
+
+1. Agreement on branch out deadline: By consensus during the call
+2. Publication in social media & mailing list about deadline:
+3. Project board with the name for the new release gets created:
+   1. The board must include a `patch version` field (selectable)
+4. Until the branch out date
+   1. All the PR/Issues that a contributor wants to finish before the deadline gets added to the Project Board
+   2. All the release blocking Issues / PRs gets added to the Project Board by each Maintainer
+
+On the branch out date, the `release/Major.minor` branch gets branched out and a `Major.minor.0-beta1` gets released for testing.
+
+#### Beta testing
+
+Before the new major/minor release, the beta version gets released for a testing phase. During the beta testing phase following changes are **allowed**:
+
+- Critical bug fixes
+- New hardware support
+
+And following changes are **not allowed**:
+
+- Big new features
+- Refactors (with no functional changes)
+
+During the beta testing, the procedure is:
+
+1. During the weekly coordination call
+   1. Remaining issues for the next beta release gets discussed, and maintainers make an effort to resolve all issues before the next beta release
+   2. Discussion on certain PRs that may be worth to be included in the next beta gets discussed, and gets added to Project Board appropriately
+2. Test reports from users get collected as a Github Issue / Discord message / Flight Review log / Discuss forum post
+   1. User-reported issues will be discussed by the maintainer team, and the maintainer in charge of the sector creates / adds an Issue to keep track of it in the Project tracker and assign the next beta version to it's `patch version` field.
+
+#### Maintainers Agreement before the release
+
+Once the release branch reaches a mature state with reliable firmware builds and no major issues are reported, the maintainer team votes to promote the branch to a stable release.
+
+##### What should maintainers look for when making a decision?
+
+- The [core functionality](../concept/core_components.md) that they maintain has been tested, and has no major issues
+- All the outstanding issues/PRs with `patch version` as the last beta version are resolved
+
+#### Point/Patch Releases
+
+Patch releases are the ones where we apply a patch (e.g. bugfix, hardware support) to a previous point release without big feature changes. Often, we need a quick patch release after the point release, as the number of testing increases significantly & new errors get found.
+
+Only the following **allowed** changes will be accepted for patch releases:
+
+- Critical bug fixes
+- New hardware support
+
+Procedure:
+
+1. The `patch version` of the last beta release (e.g. `M.m.0-beta9`) gets renamed to include the release name (e.g. `M.m.0/M.m.0-beta9`)
+2. New tag for the last release commit gets tagged (as `M.m.0`) by the 'Release manager'
+3. Release notes are prepared in Github side collaboratively by maintainers
+4. Public new point release announcement gets made via Social media / Mailing list by the 'Release manager'