Remove badges > ~2yrs old

Version 1.8.0 of rippled was released in late 2021, so any changes prior
to that are historical and no longer need badges.

Fixes #1978

content/@i18n/ja/references/protocol/ledger-data/ledger-entry-types/ticket.md

@@ -11,7 +11,7 @@ labels:
 
 _([TicketBatch amendment][]が必要です)_
 
-`Ticket`オブジェクトタイプは、将来の使用のために確保されたアカウント[シーケンス番号](../../data-types/basic-data-types.md#アカウントシーケンス)を追跡する[Ticket](../../../../concepts/accounts/tickets.md)を表します。[TicketCreate トランザクション][]で新しいチケットを作成することができます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}New in: rippled 1.7.0{% /badge %}.
+`Ticket`オブジェクトタイプは、将来の使用のために確保されたアカウント[シーケンス番号](../../data-types/basic-data-types.md#アカウントシーケンス)を追跡する[Ticket](../../../../concepts/accounts/tickets.md)を表します。[TicketCreate トランザクション][]で新しいチケットを作成することができます。
 
 ## {% $frontmatter.seo.title %} JSONの例
 

content/concepts/networks-and-servers/peer-protocol.md

@@ -63,7 +63,7 @@ The node key pair also identifies other servers for purposes of [clustering](clu
 Normally, a `rippled` server attempts to maintain a healthy number of peers, and automatically connects to untrusted peers up to a maximum number. You can configure a `rippled` server to remain connected to specific peer servers in several ways:
 
 - Use **Fixed Peers** to remain always connected to specific other peers based on their IP addresses. This only works if the peers have fixed IP addresses. Use the `[ips_fixed]` config stanza to configure fixed peers. This is a necessary part of [clustering](clustering.md) or [private peers](#private-peers). Fixed peers are defined in the config file, so changes only apply after restarting the server. Fixed peers are most useful for keeping servers connected if those servers are run by the same person or organization.
-- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers run by different people or organizations. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.4.0" %}New in: rippled 1.4.0{% /badge %} <!-- STYLE_OVERRIDE: prioritize -->
+- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers run by different people or organizations. <!-- STYLE_OVERRIDE: prioritize -->
 
 In the following cases, a `rippled` server does not connect to untrusted peers:
 
@@ -83,7 +83,7 @@ Configuring a server as a private server has several effects:
 - The server does not accept incoming connections from other servers unless it has been explicitly configured to accept connections from those servers.
 - The server asks its direct peers not to reveal its IP address in untrusted communications, including the [peer crawler API response](../../references/http-websocket-apis/peer-port-methods/peer-crawler.md). This does not affect trusted communications such as the [peers admin method][peers method].
 
-    Validators always ask their peers to hide the validators' IP addresses, regardless of the private server settings. This helps protect validators from being overloaded by denial of service attacks. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}New in: rippled 1.2.1{% /badge %}
+    Validators always ask their peers to hide the validators' IP addresses, regardless of the private server settings. This helps protect validators from being overloaded by denial of service attacks.
 
     **Caution:** It is possible to modify a server's source code so that it ignores this request and shares its immediate peers' IP addresses anyway. You should configure your private server to connect only to servers that you know are not modified in this way.
 

content/concepts/networks-and-servers/rippled-server-modes.md

@@ -13,7 +13,7 @@ The `rippled` server software can run in several modes depending on its configur
     - [**Validator**](#validators) - Helps secure the network by participating in consensus.
     - [**API Server**](#api-servers) - Provides [API access](../../tutorials/get-started/get-started-using-http-websocket-apis.md) to read data from the shared ledger, submit transactions, and watch activity in the ledger. Optionally, this can be a [**Full History Server**](#full-history-servers), which keeps a complete record of transaction and ledger history.
     - [**Hub Server**](#public-hubs) - Relays messages between many other members of the peer-to-peer network.
-- [**Reporting mode**](#reporting-mode) - A specialized mode for serving API requests from a relational database. It does not participate in the peer-to-peer network, so you need to run a P2P Mode server and connect the reporting mode server using a trusted gRPC connection. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}New in: rippled 1.7.0{% /badge %}
+- [**Reporting mode**](#reporting-mode) - A specialized mode for serving API requests from a relational database. It does not participate in the peer-to-peer network, so you need to run a P2P Mode server and connect the reporting mode server using a trusted gRPC connection. 
 - [**Stand-alone mode**](#stand-alone-mode) - An offline mode for testing. Does not connect to the peer-to-peer network or use consensus.
 
 You can also run the `rippled` executable as a client application for accessing [`rippled` APIs](../../references/http-websocket-apis/index.md) locally. (Two instances of the same binary can run side-by-side in this case; one as a server, and the other running briefly as a client and then terminating.)
@@ -68,7 +68,7 @@ For more information about running a validator, see [Run `rippled` as a Validato
 
 
 ## Reporting Mode
-{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}New in: rippled 1.7.0{% /badge %}
+
 
 Reporting mode is specialized mode for serving API requests more efficiently. In this mode, the server gets the latest validated ledger data over [gRPC](../../infrastructure/configuration/configure-grpc.md) from a separate `rippled` server running in P2P Mode, then loads that data into a relational database ([PostgreSQL](https://www.postgresql.org/)). The reporting mode server does not directly participate in the peer-to-peer network, though it can forward requests such as transaction submission to the P2P Mode server it uses.
 

content/concepts/payment-types/partial-payments.md

@@ -74,8 +74,8 @@ You can find the `delivered_amount` field in the following places:
 | [JSON-RPC / WebSocket][] | [account_tx method][] | `result.transactions` array members' `meta.delivered_amount` |
 | [JSON-RPC / WebSocket][] | [tx method][] | `result.meta.delivered_amount` |
 | [JSON-RPC / WebSocket][] | [transaction_entry method][] | `result.metadata.delivered_amount` |
-| [JSON-RPC / WebSocket][] | [ledger method][] (with transactions expanded) | `result.ledger.transactions` array members' `metaData.delivered_amount` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}New in: rippled 1.2.1{% /badge %} |
-| [WebSocket][] | [Transaction subscriptions](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Subscription messages' `meta.delivered_amount` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}New in: rippled 1.2.1{% /badge %} |
+| [JSON-RPC / WebSocket][] | [ledger method][] (with transactions expanded) | `result.ledger.transactions` array members' `metaData.delivered_amount` |
+| [WebSocket][] | [Transaction subscriptions](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md#transaction-streams) | Subscription messages' `meta.delivered_amount` |
 | ripple-lib v1.x | `getTransaction` method | `outcome.deliveredAmount` |
 | ripple-lib v1.x | `getTransactions` method | array members' `outcome.deliveredAmount` |
 

content/infrastructure/commandline-usage.md

@@ -138,7 +138,7 @@ While running unit tests, you can specify the [Generic Options](#generic-options
 
 | Option                             | Short Version | Description             |
 |:-----------------------------------|:--------------|:------------------------|
-| `--unittest-ipv6`                  |               | Use [IPv6](https://en.wikipedia.org/wiki/IPv6) to connect to the local server when running unit tests. If not provided, unit tests use IPv4 instead. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.1.0" %}New in: rippled 1.1.0{% /badge %} |
+| `--unittest-ipv6`                  |               | Use [IPv6](https://en.wikipedia.org/wiki/IPv6) to connect to the local server when running unit tests. If not provided, unit tests use IPv4 instead. |
 | `--unittest-jobs {NUMBER_OF_JOBS}` |               | Use the specified number of processes to run unit tests. This can finish running tests faster on multi-core systems. The `{NUMBER_OF_JOBS}` should be a positive integer indicating the number of processes to use. |
 | `--unittest-log`                   |               | Allow unit tests to write to logs even if `--quiet` is specified. (No effect otherwise.) |
 | `--quiet`                          | `-q`          | Print fewer diagnostic messages when running unit tests. |

content/infrastructure/configuration/data-retention/configure-history-sharding.md

@@ -25,7 +25,7 @@ Before you configure your `rippled` server to store history shards, you must dec
 - The history shard store and the ledger store _MUST_ be stored at different file paths. You can configure the ledger store and history store to be on different disks or partitions if desired.
 - It is possible but redundant to hold full ledger history in both the ledger store and the history shard store.
 - The time to acquire a shard, number of file handles needed by the `rippled` server, and memory cache usage is directly affected by the size of the shard.
-- You can specify additional paths to store older history shards by providing a `[historical_shard_paths]` stanza. These paths may be on different, slower disks because they hold data that is used less often. The most recent two shards (the ones with the largest ledger indexes) are always stored in the path specified in the `[shard_db]` stanza. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}New in: rippled 1.7.0{% /badge %}
+- You can specify additional paths to store older history shards by providing a `[historical_shard_paths]` stanza. These paths may be on different, slower disks because they hold data that is used less often. The most recent two shards (the ones with the largest ledger indexes) are always stored in the path specified in the `[shard_db]` stanza. 
 
 ## 2. Edit rippled.cfg
 
@@ -48,7 +48,7 @@ max_historical_shards=12
 /mnt/disk2
 ```
 
-The `type` field of `[shard_db]` can be omitted. If present, it _MUST_ be `NuDB`. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.3.1" %}New in: rippled 1.3.1{% /badge %}
+The `type` field of `[shard_db]` can be omitted. If present, it _MUST_ be `NuDB`.
 
 **Caution:** If `rippled` detects the wrong type of data in the shard store path, it may [fail to start](../../troubleshooting/server-wont-start.md). You should use a new folder for the shard store. If you previously used a RocksDB shard store (`rippled` 1.2.x and lower), use a different path or delete the RocksDB shard data.
 

content/infrastructure/configuration/data-retention/online-deletion.md

@@ -9,7 +9,7 @@ labels:
 # Online Deletion
 [[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
 
-The online deletion feature lets the `rippled` server delete the server's local copy of old ledger versions to keep disk usage from rapidly growing over time. The default config file sets online deletion to run automatically, but online deletion can also be configured to run only when prompted. {% badge href="https://github.com/XRPLF/rippled/releases/tag/0.27.0" %}New in: rippled 0.27.0{% /badge %}
+The online deletion feature lets the `rippled` server delete the server's local copy of old ledger versions to keep disk usage from rapidly growing over time. The default config file sets online deletion to run automatically, but online deletion can also be configured to run only when prompted.
 
 The server always keeps the complete _current_ state of the ledger, with all the balances and settings it contains. The deleted data includes older transactions and versions of the ledger state that are older than the stored history.
 

content/infrastructure/configuration/enable-public-signing.md

@@ -8,7 +8,7 @@ labels:
 ---
 # Enable Public Signing
 
-By default, the signing methods for [`rippled`](../../concepts/networks-and-servers/index.md) are limited to [administrative connections](../../references/http-websocket-apis/admin-api-methods/index.md). If you want to allow signing methods to be used as public API methods (like with versions of `rippled` before v1.1.0), you can enable it with a configuration change. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.1.0" %}New in: rippled 1.1.0{% /badge %}
+By default, the signing methods for [`rippled`](../../concepts/networks-and-servers/index.md) are limited to [administrative connections](../../references/http-websocket-apis/admin-api-methods/index.md). If you want to allow signing methods to be used as public API methods (like with versions of `rippled` before v1.1.0), you can enable it with a configuration change.
 
 This enables the following methods to be used on "public" [JSON-RPC and WebSocket connections](../../tutorials/get-started/get-started-using-http-websocket-apis.md), if your server accepts them:
 

content/infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md

@@ -27,7 +27,7 @@ In a genesis ledger, the [genesis address](../../concepts/accounts/addresses.md#
 
 In a new genesis ledger, the hard-coded default [Reserve](../../concepts/accounts/reserves.md) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](../../concepts/consensus-protocol/fee-voting.md))
 
-By default, a new genesis ledger has no [amendments](../../concepts/networks-and-servers/amendments.md) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](../../references/protocol/transactions/pseudo-transaction-types/enableamendment.md) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the config file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](advance-the-ledger-in-stand-alone-mode.md).) {% badge href="https://github.com/XRPLF/rippled/releases/tag/0.50.0" %}New in: rippled 0.50.0{% /badge %}
+By default, a new genesis ledger has no [amendments](../../concepts/networks-and-servers/amendments.md) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](../../references/protocol/transactions/pseudo-transaction-types/enableamendment.md) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the config file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](advance-the-ledger-in-stand-alone-mode.md).)
 
 ## See Also
 

content/infrastructure/troubleshooting/diagnosing-problems.md

@@ -130,7 +130,7 @@ For a more thorough explanation of various types of log messages, see [Understan
 
 If you have problems diagnosing the problem, or you are unable to resolve the problem with any of the common fixes, you may want to ask for help in a support forum or the [GitHub issues](https://github.com/XRPLF/rippled/issues). When asking for help, you can use an info collection script to gather information about your system to help others diagnose the issue.
 
-The official package installation (for [Ubuntu/Debian](../installation/install-rippled-on-ubuntu.md) or [CentOS/RedHat](../installation/install-rippled-on-centos-rhel-with-yum.md)) installs such a script by default, to `/opt/ripple/bin/getRippledInfo`. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.5.0" %}New in: rippled 1.5.0{% /badge %} If you compiled `rippled` yourself, you can find the same script [in the `rippled` source code repository](https://github.com/XRPLF/rippled/blob/develop/bin/getRippledInfo).
+The official package installation (for [Ubuntu/Debian](../installation/install-rippled-on-ubuntu.md) or [CentOS/RedHat](../installation/install-rippled-on-centos-rhel-with-yum.md)) installs such a script by default, to `/opt/ripple/bin/getRippledInfo`. If you compiled `rippled` yourself, you can find the same script [in the `rippled` source code repository](https://github.com/XRPLF/rippled/blob/develop/bin/getRippledInfo).
 
 To use the script:
 

content/infrastructure/troubleshooting/fix-sqlite-tx-db-page-size-issue.md

@@ -23,7 +23,7 @@ The capacity of the SQLite database is a result of the database's _page size_ pa
 
 If your server is vulnerable to this problem, you can detect it two ways:
 
-- You can detect the problem [proactively](#proactive-detection) (before it causes problems) if your `rippled` server is [version 1.1.0][New in: rippled 1.1.0] or later.
+- You can detect the problem [proactively](#proactive-detection) (before it causes problems) if your `rippled` server is version 1.1.0 or later.
 - You can identify the problem [reactively](#reactive-detection) (when your server is crashing) on any `rippled` version.
 
 In both cases, detection of the problem requires access to `rippled`'s server logs.
@@ -32,7 +32,7 @@ In both cases, detection of the problem requires access to `rippled`'s server lo
 
 ### Proactive Detection
 
-To detect the SQLite page size problem proactively, you must be running **[rippled 1.1.0][New in: rippled 1.1.0] or later**. The `rippled` server writes a message such as the following in its debug log periodically, at least once every 2 minutes. (The exact numeric values from the log entry and the path to your transaction database depend on your environment.)
+To detect the SQLite page size problem proactively, you must be running **`rippled` 1.1.0 or later**. The `rippled` server writes a message such as the following in its debug log periodically, at least once every 2 minutes. (The exact numeric values from the log entry and the path to your transaction database depend on your environment.)
 
 ```text
 Transaction DB pathname: /opt/rippled/transaction.db; SQLite page size: 1024
@@ -75,7 +75,7 @@ You can fix this issue using `rippled` on supported Linux systems according to t
 
 ### Prerequisites
 
-- You must be running **[rippled version 1.1.0][New in: rippled 1.1.0] or later**.
+- You must be running **`rippled` version 1.1.0 or later**.
 
     - [Upgrade rippled](../installation/index.md) to the latest stable version before starting this process.