docs: Update badges to remove the planned for part in v1.18 (#26637)

docs/en/debug/asset_tracking.md

@@ -1,6 +1,6 @@
 # Asset Tracking
 
-<Badge type="tip" text="main (planned for: PX4 v1.18)" />
+<Badge type="tip" text="PX4 v1.18" />
 
 PX4 can track and log detailed information about external hardware devices connected to the flight controller.
 This enables unique identification of vehicle parts throughout their operational lifetime using device IDs, serial numbers, and version information.

docs/en/middleware/uxrce_dds.md

@@ -324,7 +324,7 @@ The configuration can be done using the [UXRCE-DDS parameters](../advanced_confi
   - [UXRCE_DDS_NS_IDX](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) <Badge type="tip" text="PX4 v1.17" />: Index-based namespace definition.
     Setting this parameter to any value other than `-1` creates a namespace with the prefix `uav_` and the specified value, e.g. `uav_0`, `uav_1`, etc.
     See [namespace](#customizing-the-namespace) for methods to define richer or arbitrary namespaces.
-  - [`UXRCE_DDS_FLCTRL`](../advanced_config/parameter_reference.md#UXRCE_DDS_FLCTRL) <Badge type="tip" text="main (planned for: PX4 v1.18)" />: Serial port hardware flow control enable.
+  - [`UXRCE_DDS_FLCTRL`](../advanced_config/parameter_reference.md#UXRCE_DDS_FLCTRL) <Badge type="tip" text="PX4 v1.18" />: Serial port hardware flow control enable.
     To use hardware flow control, a custom MicroXRCE Agent needs to be adopted. Please refer to [this PR](https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/407) for the required changes, cherry-pick them on top of the [agent version](#build-run-within-ros-2-workspace) you need to use and then run the agent with the additional `--flow-control` option.
 
 ::: info
@@ -542,7 +542,7 @@ Each (`topic`,`type`) pairs defines:
 4. The message type (`VehicleOdometry`, `VehicleStatus`, `OffboardControlMode`, etc.) and the ROS 2 package (`px4_msgs`) that is expected to provide the message definition.
 5. **(Optional)**: An additional `rate_limit` field (only for publication entries), which specifies the maximum rate (Hz) at which messages will be published on this topic by PX4 to ROS 2.
    If left unspecified, the maximum publication rate limit is set to 100 Hz.
-6. <Badge type="tip" text="main (planned for: PX4 v1.18)" /> **(Optional)**: An additional `instance` field (only for publication entries), which lets you select which instance of a [multi-instance topic](./uorb.md#multi-instance) you want to be published to ROS 2.
+6. <Badge type="tip" text="PX4 v1.18" /> **(Optional)**: An additional `instance` field (only for publication entries), which lets you select which instance of a [multi-instance topic](./uorb.md#multi-instance) you want to be published to ROS 2.
    If provided, this option changes the ROS 2 topic name of the advertised uORB topic appending the instance number: `fmu/out/[uorb topic name][instance]` (plus eventual namespace and message version).
    In the example above the final topic name would be `/fmu/out/vehicle_imu1`.
 
@@ -566,7 +566,7 @@ Add a topic to the `subscriptions_multi` section to:
 - Without `route_field`, this guarantees separation between PX4 and ROS 2 publishers, but not among multiple ROS 2 publishers. In that scenario, their messages will still be routed to the same instance.
 - This is the desired behavior, for example, when you want PX4 to log the readings of two equal sensors; they will both publish on the same topic, but one will use instance 0 and the other will use instance 1.
 
-<Badge type="tip" text="main (planned for: PX4 v1.18)" /> Optionally, add `route_field` and `max_instances` to demultiplex a single ROS 2 topic into multiple uORB instances based on a message field value:
+<Badge type="tip" text="PX4 v1.18" /> Optionally, add `route_field` and `max_instances` to demultiplex a single ROS 2 topic into multiple uORB instances based on a message field value:
 
 - Each unique value of `route_field` is dynamically assigned to a separate uORB instance on first arrival, up to `max_instances`.
   For example, a single `/fmu/in/aux_global_position` ROS 2 topic can be demultiplexed to up to 4 separate uORB instances of `aux_global_position`, with each unique `id` value mapped to its own instance.

docs/en/middleware/zenoh.md

@@ -1,6 +1,6 @@
 # Zenoh (PX4 ROS 2 rmw_zenoh)
 
-<Badge type="tip" text="main (planned for: PX4 v1.17)" /> <Badge type="warning" text="Experimental" />
+<Badge type="tip" text="PX4 v1.17" /> <Badge type="warning" text="Experimental" />
 
 :::warning Experimental
 At the time of writing, PX4 Zenoh-pico is experimental, and hence subject to change.

docs/en/neural_networks/raptor.md

@@ -1,6 +1,6 @@
 # RAPTOR: A Neural Network Module for Adaptive Quadrotor Control
 
-<Badge type="tip" text="main (planned for PX4 v1.18)" /> <Badge type="info" text="Multicopter" /> <Badge type="warning" text="Experimental" />
+<Badge type="tip" text="PX4 v1.18" /> <Badge type="info" text="Multicopter" /> <Badge type="warning" text="Experimental" />
 
 ::: warning
 This is an experimental module.

docs/en/releases/1.17.md

@@ -13,7 +13,7 @@ const { site } = useData();
   </div>
 </div>
 
-This contains changes to PX4 planned for PX4 v1.17 (since the last major release [PX v1.16](../releases/1.16.md)).
+This contains changes in PX4 v1.17 (since the last major release [PX v1.16](../releases/1.16.md)).
 
 ::: warning
 PX4 v1.17 is in alpha/beta testing.

docs/en/releases/index.md

@@ -3,7 +3,7 @@
 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.
 
 - [main](../releases/main.md) (changes planned for v1.18 or later)
-- [v1.17](../releases/1.17.md) (changes planned for v1.17, since v1.16)
+- [v1.17](../releases/1.17.md) (changes in v1.17, since v1.16)
 - [v1.16](../releases/1.16.md)
 - [v1.15](../releases/1.15.md)
 - [v1.14](../releases/1.14.md)

docs/en/releases/release_process.md

@@ -45,7 +45,11 @@ Release notes are built incrementally in [`main.md`](../releases/main.md), which
 3. Reset `main.md` to a clean template for the next release cycle
 4. Verify that documentation for all included contributions is complete
 5. Search for instances of `main (planned for:` and replace with the release version now that it is known.
-   So, for example `<Badge type="tip" text="main (planned for: PX4 v1.18)" />` is replaced with `<Badge type="tip" text="PX4 v1.18" />`
+   So, for example `<Badge type="tip" text="main (planned for PX4 v1.xx" />` is replaced with `<Badge type="tip" text="PX4 v1.xx" />`.
+   
+   Note that once the name of the next version is confirmed, badges may use the second form (e.g. `<Badge type="tip" text="PX4 v1.18" />`.
+6. Search for instances of `<Badge type="warning" text="Experimental" />`.
+   Remove this for features that are considered core and/or stable.
 
 ::: tip
 Community members are encouraged to document changes as they are merged into `main`. This distributes the documentation workload and ensures changes are captured while they're fresh.