docs: remove versioned content (#124)

This removes content that is not relevant anymore for the updated
documentation, and is part of the work in our transition spec to remove
versioned content from our docs.

That information will still live in the docs in the 3.6 branch, see
#120 for more details.

Author: AloizioMacedo

rtd-docs/explanation/deploying-machines.md

@@ -47,9 +47,9 @@ Curtin supports preseed files, allowing administrators to influence how storage,
 
 Between curtin preseeds and cloud-init user-data, you can tailor deployments to a very fine level of detail.
 
-## Ephemeral OS deployments (MAAS 3.5+)
+## Ephemeral OS deployments
 
-Since MAAS 3.5, you can choose to deploy an ephemeral OS instance:
+You can choose to deploy an ephemeral OS instance:
 
 - The entire operating system runs from memory, with no disk installation.
 - This is useful for stateless workloads, temporary testing, or security-sensitive use cases.

rtd-docs/explanation/logging.md

@@ -2,11 +2,11 @@
 
 This page describes basic MAAS logging operations.
 
-## Logging updates in MAAS 3.5
+## Logging in MAAS
 
-In 3.5, the MAAS snap uses the [Pebble](https://github.com/canonical/pebble) service manager instead of `supervisord`. This means that the `systemd` component was renamed to `snap.maas.pebble.service`.  It contains Pebble logs, as well as intercepted stdout of the services running under Pebble.  The region and rack logs are cached there, as well (i.e., `regiond.log` and `rackd.log` are no more -- supervisord was redirecting the stdout of the respective services).
+The MAAS snap uses the [Pebble](https://github.com/canonical/pebble) service manager, with the systemd component being named `snap.maas.pebble.service`.  It contains Pebble logs, as well as intercepted stdout of the services running under Pebble. The region and rack logs are cached there, as well.
 
-Here is a per-service breakdown how logging works in MAAS 3.5:
+Here is a per-service breakdown how logging works in MAAS:
 
 ### Pebble
 

rtd-docs/explanation/machine-customization.md

@@ -13,7 +13,7 @@ Before a machine is deployed, you can customise:
 
 ## Post-deployment detection
 
-From MAAS 3.2 onward, you can modify a running machine outside MAAS (e.g. by swapping hardware or adjusting a VM definition). MAAS can then detect:
+You can modify a running machine outside MAAS (e.g. by swapping hardware or adjusting a VM definition). MAAS can then detect:
 
 - Added or removed disks.
 - Added or removed NICs.

rtd-docs/how-to-guides/deploy-a-fips-kernel.md

@@ -21,7 +21,7 @@ The  kernel FIPS kernel isn't directly integrated into MAAS. Instead, cloud-init
 ## What you'll need
 
 1. Valid Ubuntu Pro token (find yours at [Ubuntu Pro Dashboard](https://ubuntu.com/pro/dashboard)^^*^^).
-2. MAAS 3.2 or later with Ubuntu 22.04 LTS images.
+2. Ubuntu 22.04 LTS images.
 3. A host compatible with Ubuntu FIPS-compliant kernel.
 4. Internet connection.
 

rtd-docs/how-to-guides/deploy-a-real-time-kernel.md

@@ -23,7 +23,7 @@ The RT kernel isn't directly integrated into MAAS. Instead, cloud-init is used t
 ## What you'll need
 
 1. Valid Ubuntu Pro token (find yours at [Ubuntu Pro Dashboard](https://ubuntu.com/pro/dashboard)^^*^^).
-2. MAAS 3.2 or later with Ubuntu 22.04 LTS images.
+2. Ubuntu 22.04 LTS images.
 3. A host compatible with Ubuntu RT kernel.
 4. Internet connection.
 

rtd-docs/how-to-guides/deploy-dpus.md

@@ -1,8 +1,8 @@
 # Deploy DPUs
 
-A Data Processing Unit (DPU) is a specialized network interface card that offloads networking, storage, and security tasks from the CPU. MAAS 3.7 introduced BMC-based control for NVIDIA BlueField 3 DPUs, enabling them to be managed like standard machines in the MAAS infrastructure.
+A Data Processing Unit (DPU) is a specialized network interface card that offloads networking, storage, and security tasks from the CPU. MAAS supports BMC-based control for NVIDIA BlueField 3 DPUs, enabling them to be managed like standard machines in the MAAS infrastructure.
 
-This guide explains how to configure, add, commission, deploy, and release NVIDIA BlueField 3 DPUs in MAAS 3.7 and later.
+This guide explains how to configure, add, commission, deploy, and release NVIDIA BlueField 3 DPUs.
 
 **Note**: BlueField 2 DPUs can still be added and controlled using the manual approach described in previous [documentation](https://discourse.maas.io/t/maas-and-dpus/6390). This guide focuses on the BMC-enabled workflow for BlueField 3 devices.
 
@@ -12,7 +12,6 @@ Before deploying a DPU in MAAS, ensure you have the following:
 
 ### Infrastructure Requirements
 
-- **MAAS 3.7 or later** installed and configured  
 - **NVIDIA BlueField 3 DPU** with BMC support  
 - **Host machine** powered on (the DPU resides within this host)  
 - **Network infrastructure** configured for PXE boot on the OOB management interface  

rtd-docs/how-to-guides/deploy-vms-on-ibm-z.md

@@ -1,6 +1,6 @@
 # Deploy VMs on IBM Z
 
-You can deploy virtual machines on the IBM Z series with MAAS version 3.0 or higher.
+You can deploy virtual machines on the IBM Z series with MAAS.
 
 The IBM Z or LinuxONE system can host MAAS controllers and is able to deploy predefined logical partitions (LPARs) KVM host(s), and virtual machines, if the mainframe is set up properly for MAAS.
 

rtd-docs/how-to-guides/manage-machine-groups.md

@@ -385,8 +385,6 @@ maas $PROFILE machines read | jq -r '.[] | select(.description != null and .desc
 
 Dynamic annotations are ephemeral, key–value metadata attached to machines. They only exist during allocation or deployment and are lost when the machine is released.
 
-> **Note**: Dynamic annotations are not supported in MAAS 2.9 or earlier.
-
 ### Identify eligible machines
 
 **CLI only**

rtd-docs/how-to-guides/sso.md

@@ -2,7 +2,7 @@
 
 Single Sign-On (SSO) allows users to log in to multiple applications with a single set of credentials. In MAAS, you can configure SSO using an external identity provider (IdP) that supports the OpenID Connect (OIDC) protocol.
 
-This guide explains how to configure SSO using an OIDC-compliant IdP in MAAS 3.8 and later versions.
+This guide explains how to configure SSO using an OIDC-compliant IdP in MAAS.
 
 ## Prerequisites
 

rtd-docs/how-to-guides/use-logging.md

@@ -10,9 +10,9 @@ MAAS logs help you find issues, spot configuration mistakes, and audit the use o
 
 Each of these has a specific purpose, as described in this document.
 
-## Checking logs in systemd (MAAS 3.5 and Newer)
+## Checking logs in systemd
 
-Understanding what MAAS is doing under the hood is critical when troubleshooting unexpected behavior — whether a machine fails to deploy, a controller won’t respond, or an API call returns errors. Starting with version 3.5, MAAS uses `systemd` journal logs instead of log files written to disk. This change offers a more efficient and centralized way to inspect logs, in context, in real time.
+Understanding what MAAS is doing under the hood is critical when troubleshooting unexpected behavior — whether a machine fails to deploy, a controller won’t respond, or an API call returns errors. MAAS uses `systemd` to provide an efficient and centralized way to inspect logs, in context, in real time.
 
 ### Region controller logs
 
@@ -46,16 +46,6 @@ To search for logs by machine name (hostname):
 journalctl -u snap.maas.pebble -t maas-machine --since "-15m" MAAS_MACHINE_HOSTNAME=ace-cougar
 ```
 
-## Checking logs before MAAS 3.5
-
-Before version 3.5, MAAS saved logs in custom files. Here are some examples:
-
-- Region Controller: `/var/snap/maas/common/log/regiond.log` or `/var/log/maas/regiond.log`
-
-- Rack Controller: `/var/snap/maas/common/log/rackd.log` or `/var/log/maas/rackd.log`
-
-- Proxy: `/var/snap/maas/common/log/proxy/access.log`
-
 ### Using the less command to read logs
 
 ```