Fixing links with versioned docs

docs/changelog.md

@@ -22,7 +22,7 @@ This can help overcome issues like usage of type aliases that point to internal
 
 ### :octicons-tag-24: [`v2.21.0`](https://github.com/vektra/mockery/releases/tag/v2.21.0): `#!yaml packages` configuration
 
-In this version we release the `#!yaml packages` configuration section. This new parameter allows defining specific packages to generate mocks for, while also giving fine-grained control over which interfaces are mocked, where they are located, and how they are configured. Details are provided [here](/mockery/features/#packages-configuration).
+In this version we release the `#!yaml packages` configuration section. This new parameter allows defining specific packages to generate mocks for, while also giving fine-grained control over which interfaces are mocked, where they are located, and how they are configured. Details are provided [here](features.md#packages-configuration).
 
 Community input is desired before we consider deprecations of dynamic walking (via `#!yaml all: True`): https://github.com/vektra/mockery/discussions/549
 

docs/configuration.md

@@ -57,11 +57,11 @@ These are the configuration options available when using the legacy, non-`packag
     | `testonly` | Prepend every mock file with `_test.go`. This is useful in cases where you are generating mocks `inpackage` but don't want the mocks to be visible to code outside of tests. |
     | `with-expecter` | Use `with-expecter: True` to generate `EXPECT()` methods for your mocks. This is the preferred way to setup your mocks. |
 
-### [`packages` config](/mockery/features/#packages-configuration)
+### [`packages` config](features.md#packages-configuration)
 
 These are the config options when using the `packages` config option. Use of the `packages` config semantics puts mockery into a completely different code path. Config variables may have changed meanings or have been subtracted entirely, compared to the non-`packages` config.
 
-Please see the [features section](/mockery/features/#packages-configuration) for more details on how `packages` works, including some example configuration.
+Please see the [features section](features.md#packages-configuration) for more details on how `packages` works, including some example configuration.
 
 !!! info "`packages` config"
 
@@ -79,12 +79,12 @@ Please see the [features section](/mockery/features/#packages-configuration) for
     | `mockname` | :fontawesome-solid-check: | `#!yaml "Mock{{.InterfaceName}}"` | The name of the generated mock. |
     | `outpkg` | :fontawesome-solid-check: | `#!yaml "{{.PackageName}}"` | Use `outpkg` to specify the package name of the generated mocks. |
     | `log-level` | :fontawesome-solid-x: | `#!yaml "info"` | Set the level of the logger |
-    | [`packages`](/mockery/features/#packages-configuration) | :fontawesome-solid-x: | `#!yaml null` | A dictionary containing configuration describing the packages and interfaces to generate mocks for. |
+    | [`packages`](features.md#packages-configuration) | :fontawesome-solid-x: | `#!yaml null` | A dictionary containing configuration describing the packages and interfaces to generate mocks for. |
     | `print` | :fontawesome-solid-x: | `#!yaml false` | Use `print: True` to have the resulting code printed out instead of written to disk. |
-    | [`recursive`](/mockery/features/#recursive-package-discovery) | :fontawesome-solid-x: | `#!yaml false` | When set to `true` on a particular package, mockery will recursively search for all sub-packages and inject those packages into the config map. |
+    | [`recursive`](features.md#recursive-package-discovery) | :fontawesome-solid-x: | `#!yaml false` | When set to `true` on a particular package, mockery will recursively search for all sub-packages and inject those packages into the config map. |
     | `tags` | :fontawesome-solid-x: | `#!yaml ""` | Set the build tags of the generated mocks. |
-    | [`with-expecter`](/mockery/features/#expecter-structs) | :fontawesome-solid-x: | `#!yaml true` | Use `with-expecter: True` to generate `EXPECT()` methods for your mocks. This is the preferred way to setup your mocks. |
-    | [`replace-type`](/mockery/features/#replace-types) | :fontawesome-solid-x: | `#!yaml null` | Replaces aliases, packages and/or types during generation.|
+    | [`with-expecter`](features.md#expecter-structs) | :fontawesome-solid-x: | `#!yaml true` | Use `with-expecter: True` to generate `EXPECT()` methods for your mocks. This is the preferred way to setup your mocks. |
+    | [`replace-type`](features.md#replace-types) | :fontawesome-solid-x: | `#!yaml null` | Replaces aliases, packages and/or types during generation.|
 
     -------------
 

docs/features.md

@@ -98,7 +98,7 @@ func (_m *Handler) HandleMessage(m pubsub.Message) error {
     This feature is considered beta. The feature set has been solidified, but we are asking users to beta-test for any bugs. Use at your own risk. This warning will be updated as this feature matures.
 
 !!! info
-    See the [Migration Docs](/mockery/migrating_to_packages/) on how to migrate to this new feature.
+    See the [Migration Docs](migrating_to_packages.md) on how to migrate to this new feature.
 
 Mockery has a configuration parameter called `packages`. In this config section, you define the packages and the interfaces you want mocks generated for. The packages can be any arbitrary package, either your own project or anything within the Go ecosystem. You may provide package-level or interface-level overrides to the default config you provide.
 
@@ -145,7 +145,7 @@ packages:
 !!! note
     Templated variables are only available when using the `packages` config feature.
 
-Included with this feature is the ability to use templated strings for various configuration options. This is useful to define where your mocks are placed and how to name them. You can view the template variables available in the [Configuration](/mockery/configuration/#template-variables) section of the docs.
+Included with this feature is the ability to use templated strings for various configuration options. This is useful to define where your mocks are placed and how to name them. You can view the template variables available in the [Configuration](configuration.md#template-variables) section of the docs.
 
 ### Layouts
 

docs/index.md

@@ -41,7 +41,7 @@ testonly: True # (3)!
 ```
 
 1. Generate our mocks next to the original interface
-2. Create [expecter methods](/mockery/features/#expecter-structs)
+2. Create [expecter methods](features.md#expecter-structs)
 3. Append `_test.go` to the filename so the mock object is not packaged 
 
 ```bash
@@ -84,4 +84,4 @@ Who uses mockery?
 :simple-grafana: [grafana](https://github.com/grafana/grafana) · :simple-google: [Google Skia](https://github.com/google/skia) · [Hashicorp](https://github.com/search?q=org%3Ahashicorp%20mockery&type=code) · :simple-google: [Google Skyzkaller](https://github.com/google/syzkaller) · :fontawesome-brands-uber: [Uber Cadence](https://github.com/uber/cadence) · [Jaeger](https://github.com/jaegertracing/jaeger) · [Splunk](https://github.com/splunk/kafka-mq-go) · [Ignite CLI](https://github.com/ignite/cli) · [Tendermint](https://github.com/tendermint/tendermint) · [Datadog](https://github.com/DataDog/datadog-agent)
 
 
-[Get Started](/mockery/installation/){ .md-button .md-button--primary .md-button--stretch }
+[Get Started](installation.md){ .md-button .md-button--primary .md-button--stretch }

docs/migrating_to_packages.md

@@ -2,7 +2,7 @@
 title: Migrating To Packages
 ---
 
-The [packages](/mockery/features/#packages-configuration) feature is a new configuration scheme that aims to simplify and improve a lot of legacy behavior. This will be the only way to generate mocks in v3. These docs outline general principals for migrating to the new scheme.
+The [packages](features.md#packages-configuration) feature is a new configuration scheme that aims to simplify and improve a lot of legacy behavior. This will be the only way to generate mocks in v3. These docs outline general principals for migrating to the new scheme.
 
 Background
 ----------
@@ -21,9 +21,9 @@ The existence of the `#!yaml packages:` map in your configuration acts as a feat
 
 The configuration parameters used in `packages` should be considered to have no relation to their meanings in the legacy scheme. It is recommended to wipe out all previous configuration and command-line parameters previously used.
 
-The [configuration docs](/mockery/configuration/#packages-config) show the parameters that are available for use in the `packages` scheme. You should only use the parameters shown in this section. Mockery will not prevent you from using the legacy parameter set, but doing so will result in undefined behavior.
+The [configuration docs](configuration.md#packages-config) show the parameters that are available for use in the `packages` scheme. You should only use the parameters shown in this section. Mockery will not prevent you from using the legacy parameter set, but doing so will result in undefined behavior.
 
-All of the parameters in the config section can be specified at the top level of the config file, which serves as the default values. The `packages` config section defines package-specific config. See some examples [here](/mockery/features/#examples).
+All of the parameters in the config section can be specified at the top level of the config file, which serves as the default values. The `packages` config section defines package-specific config. See some examples [here](features.md#examples).
 
 `//go:generate` directives
 ----------------------------
@@ -40,4 +40,4 @@ Filesystem Tree Layouts
 
 The legacy config provided the `keeptree` parameter which, if `#!yaml keeptree: True`, would place the mocks in the same package as your interfaces. Otherwise, it would place it in a separate directory.
 
-These two layouts are supported in the `packages` scheme. See the relevant docs [here](/mockery/features/#layouts).
+These two layouts are supported in the `packages` scheme. See the relevant docs [here](features.md#layouts).