feat: swap to a version tag rather than strict versioning

CONTRIBUTING.md

@@ -151,12 +151,14 @@ of a few ways:
     %%_MAJ_MIN_PAT_USERDEV_%% - Latest Paperweight-Userdev Version (E.g. 1.7.3)
     ````
 
-When the major version of the software changes, the docs will still need to have a "snapshot" created to keep documentation
-for older versions. This is done by using Docusaurus's `version` command:
+### Manual Version Tagging
 
-```bash
-pnpm docusaurus docs:version:paper "1.20"
-```
+All of our documentation which is potentially relevant to a specific version of the software should be tagged with the
+`targetVersion` frontmatter. This allows the user to see which version of the software the documentation was written for.
+
+It is important to keep this up to date, as it allows users to see if the documentation is still relevant to the version
+however it is not required for all documentation. For example, a page about the history of the project would not need a
+`targetVersion` tag.
 
 ## Magic Value Handling
 

_redirects

@@ -8,3 +8,5 @@
 /paper/configuration /paper/reference/configuration
 /paper/reference/vanilla-command-permissions /paper/reference/permissions
 /paper/dev/commands /paper/dev/command-api/commands
+/paper/:version/* /paper/*
+/paper/:version /paper

config/navbar.config.ts

@@ -82,11 +82,6 @@ const navbar: Omit<Navbar, "style" | "hideOnScroll"> = {
       label: "Misc",
       position: "left",
     },
-    {
-      type: "docsVersionDropdown",
-      docsPluginId: "paper",
-      position: "right",
-    },
     {
       to: "https://papermc.io/downloads",
       label: "Downloads",

docs/folia/admin/reference/faq.md

@@ -2,6 +2,7 @@
 slug: /faq
 title: FAQ
 description: Questions frequently asked by our community, answered by us!
+targetVersion: 1.21
 ---
 
 # FAQ

docs/folia/admin/reference/overview.md

@@ -2,6 +2,7 @@
 slug: /reference/overview
 title: Overview
 description: An overview of how Folia works.
+targetVersion: 1.21
 ---
 
 # Project overview

docs/folia/admin/reference/region-logic.md

@@ -2,27 +2,28 @@
 slug: /reference/region-logic
 title: Region Logic
 description: An overview to how Folia's regionizer works.
+targetVersion: 1.21
 ---
 
 ## Fundamental regionizing logic
 
 ## Region
 
-A region is simply a set of owned chunk positions and implementation 
+A region is simply a set of owned chunk positions and implementation
 defined unique data object tied to that region. It is important
 to note that for any non-dead region x, that for each chunk position y
 it owns that there is no other non-dead region z such that
 the region z owns the chunk position y.
 
 ## Regionizer
 
-Each world has its own regionizer. The regionizer is a term used 
+Each world has its own regionizer. The regionizer is a term used
 to describe the logic that the class `ThreadedRegionizer` executes
-to create, maintain, and destroy regions. Maintenance of regions is 
-done by merging nearby regions together, marking which regions 
-are eligible to be ticked, and finally by splitting any regions 
-into smaller independent regions. Effectively, it is the logic 
-performed to ensure that groups of nearby chunks are considered 
+to create, maintain, and destroy regions. Maintenance of regions is
+done by merging nearby regions together, marking which regions
+are eligible to be ticked, and finally by splitting any regions
+into smaller independent regions. Effectively, it is the logic
+performed to ensure that groups of nearby chunks are considered
 a single independent region.
 
 ## Guarantees the regionizer provides
@@ -37,12 +38,12 @@ has one, and only one, corresponding region.
 
 ### Second invariant
 
-The second invariant is that for every _existing_ chunk holder x that is 
-contained in a region that every each chunk position within the 
-"merge radius" of x is owned by the region. Effectively, this invariant 
+The second invariant is that for every _existing_ chunk holder x that is
+contained in a region that every each chunk position within the
+"merge radius" of x is owned by the region. Effectively, this invariant
 guarantees that the region is not close to another region, which allows
 the region to assume while ticking it can create data for chunk holders
-"close" to it. 
+"close" to it.
 
 ### Third invariant
 
@@ -51,24 +52,24 @@ the chunk positions it owns as it ticks. The third invariant
 is important as it prevents ticking regions from "fighting"
 over non-owned nearby chunks, to ensure that they truly tick
 in parallel, no matter what chunk loads they may issue while
-ticking. 
+ticking.
 
-To comply with the first invariant, the regionizer will 
-create "transient" regions _around_ ticking regions. Specifically, 
-around in this context means close enough that would require a merge, 
+To comply with the first invariant, the regionizer will
+create "transient" regions _around_ ticking regions. Specifically,
+around in this context means close enough that would require a merge,
 but not far enough to be considered independent. The transient regions
-created in these cases will be merged into the ticking region 
+created in these cases will be merged into the ticking region
 when the ticking region finishes ticking.
 
-Both of the second invariant and third invariant combined allow 
+Both of the second invariant and third invariant combined allow
 the regionizer to guarantee that a ticking region may create
 and then access chunk holders around it (i.e. sync loading) without
 the possibility that it steps on another region's toes.
 
 ### Fourth invariant
 
 The fourth invariant is that a region is only in one of four
-states: "transient", "ready", "ticking", or "dead." 
+states: "transient", "ready", "ticking", or "dead."
 
 The "ready" state allows a state to transition to the "ticking" state,
 while the "transient" state is used as a state for a region that may
@@ -90,22 +91,22 @@ The regionizer does not operate on chunk coordinates, but rather
 on "region section coordinates." Region section coordinates simply
 represent a grouping of NxN chunks on a grid, where N is some power
 of two. The actual number is left ambiguous, as region section coordinates
-are only an internal detail of how chunks are grouped. 
-For example, with N=16 the region section (0,0) encompasses all 
-chunks x in [0,15] and z in [0,15]. This concept is similar to how 
-the chunk coordinate (0,0) encompasses all blocks x in [0, 15] 
-and z in [0, 15]. Another example with N=16, the chunk (17, -5) is 
-contained within region section (1, -1). 
+are only an internal detail of how chunks are grouped.
+For example, with N=16 the region section (0,0) encompasses all
+chunks x in [0,15] and z in [0,15]. This concept is similar to how
+the chunk coordinate (0,0) encompasses all blocks x in [0, 15]
+and z in [0, 15]. Another example with N=16, the chunk (17, -5) is
+contained within region section (1, -1).
 
 Region section coordinates are used only as a performance
 tradeoff in the regionizer, as by approximating chunks to their
 region coordinate allows it to treat NxN chunks as a single
 unit for regionizing. This means that regions do not own chunks positions,
-but rather own region section positions. The grouping of NxN chunks 
-allows the regionizing logic to be performed only on 
+but rather own region section positions. The grouping of NxN chunks
+allows the regionizing logic to be performed only on
 the creation/destruction of region sections.
 For example with N=16 this means up to NxN-1=255 possible
-less operations in areas such as addChunk/region recalculation 
+less operations in areas such as addChunk/region recalculation
 assuming region sections are always full.
 
 ### Implementation variables
@@ -119,33 +120,33 @@ The recalculation count is the minimum number of region sections
 that a region must own to allow it to re-calculate. Note that
 a recalculation operation simply calculates the set of independent
 regions that exist within a region to check if a split can be
-performed. 
-This is a simple performance knob that allows split logic to be 
-turned off for small regions, as it is unlikely that small regions 
+performed.
+This is a simple performance knob that allows split logic to be
+turned off for small regions, as it is unlikely that small regions
 can be split in the first place.
 
 #### Max dead section percent
 
-The max dead section percent is the minimum percent of dead 
+The max dead section percent is the minimum percent of dead
 sections in a region that must exist before a region can run
 re-calculation logic.
 
 #### Empty section creation radius
 
 The empty section creation radius variable is used to determine
-how many empty region sections are to exist around _any_ 
-region section with at least one chunk. 
+how many empty region sections are to exist around _any_
+region section with at least one chunk.
 
 Internally, the regionizer enforces the third invariant by
 preventing ticking regions from owning new region sections.
-The creation of empty sections around any non-empty section will 
+The creation of empty sections around any non-empty section will
 then enforce the second invariant.
 
 #### Region section merge radius
 
 The merge radius variable is used to ensure that for any
 existing region section x that for any other region section y within
-the merge radius are either owned by region that owns x 
+the merge radius are either owned by region that owns x
 or are pending a merge into the region that owns x or that the
 region that owns x is pending a merge into the region that owns y.
 
@@ -160,15 +161,15 @@ region coordinate = chunk coordinate >> region section chunk shift.
 
 The regionizer is operated by invoking `ThreadedRegionizer#addChunk(x, z)`
 or `ThreadedRegionizer#removeChunk(x, z)` when a chunk holder is created
-or destroyed. 
+or destroyed.
 
 Additionally, `ThreadedRegion#tryMarkTicking` can be used by a caller
 that attempts to move a region from the "ready" state to the "ticking"
-state. It is vital to note that this function will return false if 
+state. It is vital to note that this function will return false if
 the region is not in the "ready" state, as it is possible
 that even a region considered to be "ready" in the past (i.e. scheduled
 to tick) may be unexpectedly marked as "transient." Thus, the caller
-needs to handle such cases. The caller that successfully marks 
+needs to handle such cases. The caller that successfully marks
 a region as ticking must mark it as non-ticking by using
 `ThreadedRegion#markNotTicking`.
 
@@ -184,12 +185,12 @@ may additionally be considered "non-empty" if it contains
 at least one chunk position, and "empty" otherwise.
 
 A region section is considered "dead" if and only if the region section
-is also "empty" and that there exist no other "empty" sections within the 
-empty section creation radius. 
+is also "empty" and that there exist no other "empty" sections within the
+empty section creation radius.
 
 The existence of the dead section state is purely for performance, as it
 allows the recalculation logic of a region to be delayed until the region
-contains enough dead sections. However, dead sections are still 
+contains enough dead sections. However, dead sections are still
 considered to belong to the region that owns them just as alive sections.
 
 ### Addition of chunks (`addChunk`)
@@ -219,7 +220,7 @@ and no region state is modified, and the sections are added to this
 
 Merge logic needs to occur when there are more than 1 region in the
 set X. From the set X, a region x is selected that is not ticking. If
-no such x exists, then a region x is created. Every region section 
+no such x exists, then a region x is created. Every region section
 created is added to the set x, as it is the section that is known
 to not be ticking - this is done to adhere to invariant third invariant.
 
@@ -229,27 +230,27 @@ logic into y.
 
 ### Merge later logic
 
-A merge later operation may only take place from 
+A merge later operation may only take place from
 a non-ticking, non-dead region x into a ticking region y.
 The merge later logic relies on maintaining a set of regions
 to merge into later per region, and another set of regions
 that are expected to merge into this region.
 Effectively, a merge into later operation from x into y will add y into x's
 merge into later set, and add x into y's expecting merge from set.
 
-When the ticking region finishes ticking, the ticking region 
+When the ticking region finishes ticking, the ticking region
 will perform the merge logic for all expecting merges.
 
 ### Merge logic
 
 A merge operation may only take place between a dead region x
-and another region y which may be either "transient" 
+and another region y which may be either "transient"
 or "ready." The region x is effectively absorbed into the
 region y, as the sections in x are moved to the region y.
 
-The merge into later is also forwarded to the region y, 
+The merge into later is also forwarded to the region y,
 such so that the regions x was to merge into later, y will
-now merge into later. 
+now merge into later.
 
 Additionally, if there is implementation specific data
 on region x, the region callback to merge the data into the
@@ -258,8 +259,8 @@ region y is invoked.
 The state of the region y may be updated after a merge operation
 completes. For example, if the region x was "transient", then
 the region y should be downgraded to transient as well. Specifically,
-the region y should be marked as transient if region x contained 
-merge later targets that were not y. The downgrading to transient is 
+the region y should be marked as transient if region x contained
+merge later targets that were not y. The downgrading to transient is
 required to adhere to the second invariant.
 
 ### Removal of chunks (`removeChunk`)
@@ -272,20 +273,20 @@ any region state, and nor will it purge region sections.
 ### Region tick start (`tryMarkTicking`)
 
 The tick start simply migrates the state to ticking, so that
-invariants #2 and #3 can be met. 
+invariants #2 and #3 can be met.
 
 ### Region tick end (`markNotTicking`)
 
 At the end of a tick, the region's new state is not immediately known.
 
-First, tt first must process its pending merges. 
+First, tt first must process its pending merges.
 
-After it processes its pending merges, it must then check if the 
-region is now pending merge into any other region. If it is, then 
-it transitions to the transient state. 
+After it processes its pending merges, it must then check if the
+region is now pending merge into any other region. If it is, then
+it transitions to the transient state.
 
-Otherwise, it will process the removal of dead sections and attempt 
-to split into smaller regions. Note that it is guaranteed 
+Otherwise, it will process the removal of dead sections and attempt
+to split into smaller regions. Note that it is guaranteed
 that if a region can be possibly split, it must remove dead sections,
-otherwise, this would contradict the rules used to build the region 
+otherwise, this would contradict the rules used to build the region
 in the first place.

docs/paper/admin/getting-started/adding-plugins.md

@@ -2,6 +2,7 @@
 toc_max_heading_level: 4
 slug: /adding-plugins
 description: Plugins are the most powerful way to extend the functionality of Paper beyond the configuration files.
+targetVersion: 1.21
 ---
 
 # Adding Plugins

docs/paper/admin/getting-started/getting-started.mdx

@@ -1,6 +1,7 @@
 ---
 slug: /getting-started
 description: How to get started with downloading and setting up a Paper server.
+targetVersion: 1.21
 ---
 
 # Getting Started

docs/paper/admin/getting-started/migration.md

@@ -2,6 +2,7 @@
 slug: /migration
 title: Migrating to or from Paper
 description: It's simple to migrate your server to or from Paper. This page will help you get started.
+targetVersion: 1.21
 ---
 
 It's simple to migrate your server to or from Paper. The steps below will help you get started.

docs/paper/admin/getting-started/setup-next-steps.md

@@ -1,6 +1,7 @@
 ---
 slug: /next-steps
 description: How to proceed after starting your server.
+targetVersion: 1.21
 ---
 
 # Next Steps

docs/paper/admin/how-to/aikars-flags.md

@@ -1,6 +1,7 @@
 ---
 slug: /aikars-flags
 description: Aikar's flags are a set of JVM flags designed to improve the performance of your Paper server.
+targetVersion: 1.21
 ---
 
 # Aikar's Flags

docs/paper/admin/how-to/anti-xray.mdx

@@ -1,6 +1,7 @@
 ---
 slug: /anti-xray
 description: Paper ships an obfuscation-based Anti-Xray system by default. Learn how to configure it here.
+targetVersion: 1.21
 ---
 
 # Configuring Anti-Xray

docs/paper/admin/how-to/basic-troubleshooting.md

@@ -1,6 +1,7 @@
 ---
 slug: /basic-troubleshooting
 description: This guide will help you diagnose your server's problem before reporting it to PaperMC or the plugin's author.
+targetVersion: 1.21
 ---
 
 # Basic Troubleshooting

docs/paper/admin/how-to/get-to-vanilla.mdx

@@ -1,6 +1,7 @@
 ---
 slug: /vanilla
 description: This page lists all changes that result in a different experience than Vanilla.
+targetVersion: 1.21
 ---
 
 # Vanilla-like Experience