[docs] Document the procedure for forking the dev docs

general/development/process/release/index.md

@@ -178,7 +178,7 @@ Usually on Monday
 | 3. | ✓ |  | Ensure [Language pack for `main` (X.Y+1)](https://download.moodle.org/langpack/X.Y+1/) is available and merge the pull request MR4 for stop skipping the language upgrade in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository. | Integration Team |
 | 4. | ✓ |  | Ensure release retrospectives are held for each of the LMS teams and results are actioned. | Platform Manager / Head of educational solutions |
 | 5. | &#10003; |  | <p>Prepare for the next version of PHP.</p> <p>We need to ensure that the Moodle versions that will support the next version of PHP are compatible with it.</p> <ul><li>If an epic has not been created yet, create an epic issue for it (see [MDL-80117](https://tracker.moodle.org/browse/MDL-80117) as an example)</li> <li>Go through the list of changes for the upcoming PHP version, identify potential breaking changes in Moodle and add them to the epic.</li></ul> <p>Related links:</p> <ul><li>[PHP versions](https://www.php.net/supported-versions.php)</li> <li>[PHP.Watch](https://php.watch/versions)</li> </ul> | Integration team |
-| 6. | &#10003; |  | Create a fork in Developer documentation for the major release. | Integration Team |
+| 6. | &#10003; |  | [Create a fork](../../../documentation/forking-versions.md) in Developer documentation for the major release. | Integration Team |
 
 ## 1 month after
 

general/documentation/forking-versions.md

@@ -0,0 +1,42 @@
+---
+title: Managing Moodle version documentation
+sidebar_label: Moodle versions
+tags:
+  - documentation
+  - forking
+  - versions
+---
+
+We generate version-specific documentation and maintain this for each supported version of Moodle.
+
+When a new version of Moodle is released, the documentation is 'forked'.
+
+When a version of Moodle goes out of support, its developer documentation is archived.
+
+Further information about this functionality is available in the [Docusaurus documentation on the topic](https://docusaurus.io/docs/versioning).
+
+## Creating a new version of the docs
+
+Typically this task is performed by the Integration team using the following steps:
+
+1. Ensure that all pending appropriate merge requests have been merged
+1. Ensure that your local branch is up-to-date
+1. Run the docusaurus version command:
+
+    ```bash
+    yarn docusaurus docs:version [version]
+    ```
+
+1. Commit the initial changes ([Example from Moodle 4.4](https://github.com/moodle/devdocs/commit/XXX))
+1. Open `versioned_docs/version-[version]/intro.md` in your editor
+1. Uncomment and update the link to the release notes for this version
+1. Open `docs/devupdate.md` in your editor
+1. Clear the content of this file and update the version numbers
+1. Open `nextVersion.js` in your editor
+1. Update the values for `nextVersion` and `nextLTSVersion`
+1. Commit these changes ([Example from Moodle 4.4](https://github.com/moodle/devdocs/commit/XXY))
+1. Create a pull request ([Example from Moodle 4.4](https://github.com/moodle/devdocs/pull/1006))
+
+## Archiving a version of the docs
+
+This procedure has not yet been completed and documentation will be created when we do so.