Docs cleanup for v3.5

docs/administration/error-reporting.md

@@ -4,7 +4,7 @@
 
 ### Enabling Error Reporting
 
-NetBox v3.2.3 and later support native integration with [Sentry](https://sentry.io/) for automatic error reporting. To enable this functionality, simply set `SENTRY_ENABLED` to True in `configuration.py`. Errors will be sent to a Sentry ingestor maintained by the NetBox team for analysis.
+NetBox supports native integration with [Sentry](https://sentry.io/) for automatic error reporting. To enable this functionality, simply set `SENTRY_ENABLED` to True in `configuration.py`. Errors will be sent to a Sentry ingestor maintained by the NetBox team for analysis.
 
 ```python
 SENTRY_ENABLED = True

docs/administration/permissions.md

@@ -1,6 +1,6 @@
 # Object-Based Permissions
 
-NetBox v2.9 introduced a new object-based permissions framework, which replaces Django's built-in permissions model. Object-based permissions enable an administrator to grant users or groups the ability to perform an action on arbitrary subsets of objects in NetBox, rather than all objects of a certain type. For example, it is possible to grant a user permission to view only sites within a particular region, or to modify only VLANs with a numeric ID within a certain range.
+NetBox employs a new object-based permissions framework, which replaces Django's built-in permissions model. Object-based permissions enable an administrator to grant users or groups the ability to perform an action on arbitrary subsets of objects in NetBox, rather than all objects of a certain type. For example, it is possible to grant a user permission to view only sites within a particular region, or to modify only VLANs with a numeric ID within a certain range.
 
 A permission in NetBox represents a relationship shared by several components:
 

docs/customization/custom-scripts.md

@@ -35,12 +35,9 @@ class MyScript(Script):
 
 The `run()` method should accept two arguments:
 
-* `data` - A dictionary containing all of the variable data passed via the web form.
+* `data` - A dictionary containing all the variable data passed via the web form.
 * `commit` - A boolean indicating whether database changes will be committed.
 
-!!! note
-    The `commit` argument was introduced in NetBox v2.7.8. Backward compatibility is maintained for scripts which accept only the `data` argument, however beginning with v2.10 NetBox will require the `run()` method of every script to accept both arguments. (Either argument may still be ignored within the method.)
-
 Defining script variables is optional: You may create a script with only a `run()` method if no user input is needed.
 
 Any output generated by the script during its execution will be displayed under the "output" tab in the UI.

docs/features/configuration-rendering.md

@@ -1,5 +1,7 @@
 # Configuration Rendering
 
+!!! info "This feature was introduced in NetBox v3.5."
+
 One of the critical aspects of operating a network is ensuring that every network node is configured correctly. By leveraging configuration templates and [context data](./context-data.md), NetBox can render complete configuration files for each device on your network.
 
 ```mermaid

docs/installation/2-redis.md

@@ -4,9 +4,6 @@
 
 [Redis](https://redis.io/) is an in-memory key-value store which NetBox employs for caching and queuing. This section entails the installation and configuration of a local Redis instance. If you already have a Redis service in place, skip to [the next section](3-netbox.md).
 
-!!! warning "Redis v4.0 or later required"
-    NetBox v2.9.0 and later require Redis v4.0 or higher. If your distribution does not offer a recent enough release, you will need to build Redis from source. Please see [the Redis installation documentation](https://github.com/redis/redis) for further details.
-
 === "Ubuntu"
 
     ```no-highlight

docs/models/circuits/provideraccount.md

@@ -1,17 +1,19 @@
-# Provider Accounts
-
-This model can be used to represent individual accounts associated with a provider.
-
-## Fields
-
-### Provider
-
-The [provider](./provider.md) the account belongs to.
-
-### Name
-
-A human-friendly name, unique to the provider.
-
-### Account Number
-
-The administrative account identifier tied to this provider for your organization.
+# Provider Accounts
+
+!!! info "This model was introduced in NetBox v3.5."
+
+This model can be used to represent individual accounts associated with a provider.
+
+## Fields
+
+### Provider
+
+The [provider](./provider.md) the account belongs to.
+
+### Name
+
+A human-friendly name, unique to the provider.
+
+### Account Number
+
+The administrative account identifier tied to this provider for your organization.

docs/models/ipam/asnrange.md

@@ -1,5 +1,7 @@
 # ASN Ranges
 
+!!! info "This model was introduced in NetBox v3.5."
+
 Ranges can be defined to group [AS numbers](./asn.md) numerically and to facilitate their automatic provisioning. Each range must be assigned to a [RIR](./rir.md).
 
 ## Fields

docs/plugins/development/dashboard-widgets.md

@@ -1,7 +1,6 @@
 # Dashboard Widgets
 
-!!! note "Introduced in v3.5"
-    Support for custom dashboard widgets was introduced in NetBox v3.5.
+!!! info "This feature was introduced in NetBox v3.5."
 
 Each NetBox user can customize his or her personal dashboard by adding and removing widgets and by manipulating the size and position of each. Plugins can register their own dashboard widgets to complement those already available natively.
 

docs/plugins/index.md

@@ -2,8 +2,6 @@
 
 Plugins are packaged [Django](https://docs.djangoproject.com/) apps that can be installed alongside NetBox to provide custom functionality not present in the core application. Plugins can introduce their own models and views, but cannot interfere with existing components. A NetBox user may opt to install plugins provided by the community or build his or her own.
 
-Plugins are supported on NetBox v2.8 and later.
-
 ## Capabilities
 
 The NetBox plugin architecture allows for the following: