Remove version details and history from doc files

commands/acl-getuser.md

@@ -1,10 +1,10 @@
 The command returns all the rules defined for an existing ACL user.
 
-Specifically, it lists the user's ACL flags, password hashes, commands, key patterns, channel patterns (Added in version 6.2) and selectors (Added in version 7.0).
+Specifically, it lists the user's ACL flags, password hashes, commands, key patterns, channel patterns and selectors.
 Additional information may be returned in the future if more metadata is added to the user.
 
 Command rules are always returned in the same format as the one used in the `ACL SETUSER` command.
-Before version 7.0, keys and channels were returned as an array of patterns, however in version 7.0 later they are now also returned in same format as the one used in the `ACL SETUSER` command.
+Keys and channels are returned in same format as the one used in the `ACL SETUSER` command.
 Note: This description of command rules reflects the user's effective permissions, so while it may not be identical to the set of rules used to configure the user, it is still functionally identical.
 
 Selectors are listed in the order they were applied to the user, and include information about commands, key patterns, and channel patterns.

commands/client-list.md

@@ -20,7 +20,7 @@ Here is the meaning of the fields:
 * `psub`: number of pattern matching subscriptions
 * `ssub`: number of shard channel subscriptions.
 * `multi`: number of commands in a MULTI/EXEC context
-* `watch`: number of keys this client is currently watching. Added in Valkey 8.0
+* `watch`: number of keys this client is currently watching.
 * `qbuf`: query buffer length (0 means no query pending)
 * `qbuf-free`: free space of the query buffer (0 means the buffer is full)
 * `argv-mem`: incomplete arguments for the next command (already extracted from query buffer)

commands/info.md

@@ -83,10 +83,10 @@ Here is the meaning of all fields in the **clients** section:
 *   `blocked_clients`: Number of clients pending on a blocking call (`BLPOP`,
      `BRPOP`, `BRPOPLPUSH`, `BLMOVE`, `BZPOPMIN`, `BZPOPMAX`)
 *   `tracking_clients`: Number of clients being tracked (`CLIENT TRACKING`)
-*   `pubsub_clients`: Number of clients in pubsub mode (`SUBSCRIBE`, `PSUBSCRIBE`, `SSUBSCRIBE`). Added in Valkey 8.0
-*   `watching_clients`: Number of clients in watching mode (`WATCH`). Added in Valkey 8.0
+*   `pubsub_clients`: Number of clients in pubsub mode (`SUBSCRIBE`, `PSUBSCRIBE`, `SSUBSCRIBE`).
+*   `watching_clients`: Number of clients in watching mode (`WATCH`).
 *   `clients_in_timeout_table`: Number of clients in the clients timeout table
-*   `total_watched_keys`: Number of watched keys. Added in Valkey 8.0.
+*   `total_watched_keys`: Number of watched keys.
 *   `total_blocking_keys`: Number of blocking keys.
 *   `total_blocking_keys_on_nokey`: Number of blocking keys that one or more clients that would like to be unblocked when the key is deleted.
 
@@ -153,7 +153,7 @@ Here is the meaning of all fields in the **memory** section:
 *   `mem_replication_backlog`: Memory used by replication backlog
 *   `mem_total_replication_buffers`: Total memory consumed for replication buffers.
 *   `mem_allocator`: Memory allocator, chosen at compile time.
-*   `mem_overhead_db_hashtable_rehashing`: Temporary memory overhead of database dictionaries currently being rehashed - Added in 8.0.
+*   `mem_overhead_db_hashtable_rehashing`: Temporary memory overhead of database dictionaries currently being rehashed.
 *   `active_defrag_running`: When `activedefrag` is enabled, this indicates whether defragmentation is currently active, and the CPU percentage it intends to utilize.
 *   `lazyfree_pending_objects`: The number of objects waiting to be freed (as a
      result of calling `UNLINK`, or `FLUSHDB` and `FLUSHALL` with the **ASYNC**
@@ -275,7 +275,7 @@ Here is the meaning of all fields in the **stats** section:
 *   `expire_cycle_cpu_milliseconds`: The cumulative amount of time spent on active expiry cycles
 *   `evicted_keys`: Number of evicted keys due to `maxmemory` limit
 *   `evicted_clients`: Number of evicted clients due to `maxmemory-clients` limit.
-*   `evicted_scripts`: Number of evicted EVAL scripts due to LRU policy, see `EVAL` for more details. Added in Valkey 8.0.
+*   `evicted_scripts`: Number of evicted EVAL scripts due to LRU policy, see `EVAL` for more details.
 *   `total_eviction_exceeded_time`:  Total time `used_memory` was greater than `maxmemory` since server startup, in milliseconds
 *   `current_eviction_exceeded_time`: The time passed since `used_memory` last rose above `maxmemory`, in milliseconds
 *   `keyspace_hits`: Number of successful lookup of keys in the main dictionary

commands/memory-stats.md

@@ -25,13 +25,13 @@ values. The following metrics are reported:
 *   `dbXXX`: For each of the server's databases, the overheads of the main and
      expiry dictionaries (`overhead.hashtable.main` and
     `overhead.hashtable.expires`, respectively) are reported in bytes
-*   `overhead.db.hashtable.lut`: Total overhead of dictionary buckets in databases (Added in Valkey 8.0)
-*   `overhead.db.hashtable.rehashing`: Temporary memory overhead of database dictionaries currently being rehashed (Added in Valkey 8.0) 
+*   `overhead.db.hashtable.lut`: Total overhead of dictionary buckets in databases
+*   `overhead.db.hashtable.rehashing`: Temporary memory overhead of database dictionaries currently being rehashed 
 *   `overhead.total`: The sum of all overheads, i.e. `startup.allocated`,
      `replication.backlog`, `clients.slaves`, `clients.normal`, `aof.buffer` and
      those of the internal data structures that are used in managing the
      Valkey keyspace (see `INFO`'s `used_memory_overhead`)
-*   `db.dict.rehashing.count`: Number of DB dictionaries currently being rehashed (Added in Valkey 8.0)
+*   `db.dict.rehashing.count`: Number of DB dictionaries currently being rehashed
 *   `keys.count`: The total number of keys stored across all databases in the
      server
 *   `keys.bytes-per-key`: The ratio between `dataset.bytes` and `keys.count`

docs/interact/programmability/_index.md

@@ -41,7 +41,7 @@ Every applicative instance that runs a script must have the script's source code
 That is because scripts are only cached by the server and are volatile.
 As your application grows, this approach can become harder to develop and maintain.
 
-Secondly, added in v7.0, Redis Functions are essentially scripts that are first-class database elements.
+Secondly, Redis Functions are essentially scripts that are first-class database elements.
 As such, functions decouple scripting from application logic and enable independent development, testing, and deployment of scripts.
 To use functions, they need to be loaded first, and then they are available for use by all connected clients.
 In this case, loading a function to the database becomes an administrative deployment task (such as loading a Redis module, for example), which separates the script from the application.

docs/interact/programmability/eval-intro.md

@@ -317,7 +317,7 @@ To enforce the deterministic behavior of scripts, Redis does the following:
 * Redis will block the script with an error if a script calls a Redis command able to alter the data set **after** a Redis _random_ command like `RANDOMKEY`, `SRANDMEMBER`, `TIME`.
   That means that read-only scripts that don't modify the dataset can call those commands.
   Note that a _random command_ does not necessarily mean a command that uses random numbers: any non-deterministic command is considered as a random command (the best example in this regard is the `TIME` command).
-* In Redis version 4.0, commands that may return elements in random order, such as `SMEMBERS` (because Redis Sets are _unordered_), exhibit a different behavior when called from Lua,
+* Commands that may return elements in random order, such as `SMEMBERS` (because Redis Sets are _unordered_), exhibit a different behavior when called from Lua,
 and undergo a silent lexicographical sorting filter before returning data to Lua scripts.
   So `redis.call("SMEMBERS",KEYS[1])` will always return the Set elements in the same order, while the same command invoked by normal clients may return different results even if the key contains exactly the same elements.
   However, starting with Redis 5.0, this ordering is no longer performed because replicating effects circumvents this type of non-determinism.

docs/interact/programmability/lua-api.md

@@ -87,7 +87,6 @@ Its description follows [below](#redis_object).
 
 ### <a name="the-keys-global-variable"></a>The _KEYS_ global variable
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: no
 
@@ -101,7 +100,6 @@ It is pre-populated with all key name input arguments.
 
 ### <a name="the-argv-global-variable"></a>The _ARGV_ global variable
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: no
 
@@ -110,7 +108,6 @@ It is pre-populated with all regular input arguments.
 
 ## <a name="redis_object"></a>_redis_ object
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -120,7 +117,6 @@ Following is the API provided by the _redis_ object instance.
 
 ### <a name="redis.call"></a> `redis.call(command [,arg...])`
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -147,7 +143,6 @@ To handle Redis runtime errors use `redis.pcall()` instead.
 
 ### <a name="redis.pcall"></a> `redis.pcall(command [,arg...])`
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -178,7 +173,6 @@ redis> EVAL "..." 0 hello world
 
 ### <a name="redis.error_reply"></a> `redis.error_reply(x)`
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -211,7 +205,6 @@ Scripts are advised to follow this convention, as shown in the example above, bu
 
 ### <a name="redis.status_reply"></a> `redis.status_reply(x)`
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -241,7 +234,6 @@ Refer to the [Data type conversion](#data-type-conversion) for returning other r
 
 ### <a name="redis.sha1hex"></a> `redis.sha1hex(x)`
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -256,7 +248,6 @@ redis> EVAL "return redis.sha1hex('')" 0
 
 ### <a name="redis.log"></a> `redis.log(level, message)`
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -288,7 +279,6 @@ will produce a line similar to the following in your server's log:
 
 ### <a name="redis.setresp"></a> `redis.setresp(x)`
 
-* Since version: 6.0.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -306,16 +296,12 @@ Please refer to the [Data type conversion](#data-type-conversion) for more infor
 
 ### <a name="redis.set_repl"></a> `redis.set_repl(x)`
 
-* Since version: 3.2.0
 * Available in scripts: yes
 * Available in functions: no
 
 **Note:**
-this feature is only available when script effects replication is employed.
-Calling it when using verbatim script replication will result in an error.
-As of Redis version 2.6.0, scripts were replicated verbatim, meaning that the scripts' source code was sent for execution by replicas and stored in the AOF.
-An alternative replication mode added in version 3.2.0 allows replicating only the scripts' effects.
-As of Redis version 7.0, script replication is no longer supported, and the only replication mode available is script effects replication.
+this feature is only available when script effects replication is employed,
+the replication mode available is script effects replication, And no script replication is supported.
 
 **Warning:**
 this is an advanced feature. Misuse can cause damage by violating the contract that binds the Redis master, its replicas, and AOF contents to hold the same logical content.
@@ -361,8 +347,6 @@ If you run this script by calling `EVAL "..." 3 A B C 1 2 3`, the result will be
 
 ### <a name="redis.replicate_commands"></a> `redis.replicate_commands()`
 
-* Since version: 3.2.0
-* Until version: 7.0.0
 * Available in scripts: yes
 * Available in functions: no
 
@@ -376,23 +360,20 @@ For more information, please refer to [`Replicating commands instead of scripts`
 
 ### <a name="redis.breakpoint"></a>  `redis.breakpoint()`
 
-* Since version: 3.2.0
 * Available in scripts: yes
 * Available in functions: no
 
 This function triggers a breakpoint when using the [Redis Lua debugger](/topics/ldb).
 
 ### <a name="redis.debug"></a> `redis.debug(x)`
 
-* Since version: 3.2.0
 * Available in scripts: yes
 * Available in functions: no
 
 This function prints its argument in the [Redis Lua debugger](/topics/ldb) console.
 
 ### <a name="redis.acl_check_cmd"></a> `redis.acl_check_cmd(command [,arg...])`
 
-* Since version: 7.0.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -404,7 +385,6 @@ The function will raise an error if the passed command or its arguments are inva
 
 ### <a name="redis.register_function"></a> `redis.register_function`
 
-* Since version: 7.0.0
 * Available in scripts: no
 * Available in functions: yes
 
@@ -504,7 +484,6 @@ Please refer to [Function Flags](/docs/manual/programmability/functions-intro/#f
 
 ### <a name="redis.redis_version"></a> `redis.REDIS_VERSION`
 
-* Since version: 7.0.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -517,7 +496,6 @@ The reply's format is `MM.mm.PP`, where:
 
 ### <a name="redis.redis_version_num"></a> `redis.REDIS_VERSION_NUM`
 
-* Since version: 7.0.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -656,9 +634,8 @@ That means, for example, that returning the RESP3 map type to a RESP2 connection
 ### Using `SELECT` inside scripts
 
 You can call the `SELECT` command from your Lua scripts, like you can with any normal client connection.
-However, one subtle aspect of the behavior changed between Redis versions 2.8.11 and 2.8.12.
-Prior to Redis version 2.8.12, the database selected by the Lua script was *set as the current database* for the client connection that had called it.
-As of Redis version 2.8.12, the database selected by the Lua script only affects the execution context of the script, and does not modify the database that's selected by the client calling the script.
+The database selected by the Lua script was *set as the current database* for the client connection that had called it.
+The database selected by the Lua script only affects the execution context of the script, and does not modify the database that's selected by the client calling the script.
 This semantic change between patch level releases was required since the old behavior was inherently incompatible with Redis' replication and introduced bugs.
 
 ## Runtime libraries
@@ -681,7 +658,6 @@ In addition, the following external libraries are loaded and accessible to scrip
 
 ### <a name="os-library"></a> _os_ library
 
-* Since version: 8.0.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -693,7 +669,6 @@ Note that for sandbox security, currently only the following os functions is exp
 
 ### <a name="struct-library"></a> _struct_ library
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -767,7 +742,6 @@ redis> EVAL "return struct.size('HH')" 0
 
 ### <a name="cjson-library"></a> _cjson_ library
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -798,7 +772,6 @@ redis> EVAL "return cjson.decode(ARGV[1])['foo']" 0 '{"foo":"bar"}'
 
 ### <a name="cmsgpack-library"></a> _cmsgpack_ library
 
-* Since version: 2.6.0
 * Available in scripts: yes
 * Available in functions: yes
 
@@ -831,7 +804,6 @@ redis> EVAL "return cmsgpack.unpack(ARGV[1])" 0 "\x93\xa3foo\xa3bar\xa3baz"
 
 ### <a name="bitop-library"></a> _bit_ library
 
-* Since version: 2.8.18
 * Available in scripts: yes
 * Available in functions: yes
 

docs/management/optimization/latency.md

@@ -78,9 +78,9 @@ latency that is better than the latency that every process running in your
 environment will experience because of the kernel or hypervisor implementation
 or setup.
 
-We call this kind of latency **intrinsic latency**, and `redis-cli` starting
-from Redis version 2.8.7 is able to measure it. This is an example run
-under Linux 3.11.0 running on an entry level server.
+We call this kind of latency **intrinsic latency**, and `redis-cli` is able 
+to measure it. This is an example run under Linux 3.11.0 running on an entry level 
+server.
 
 Note: the argument `100` is the number of seconds the test will be executed.
 The more time we run the test, the more likely we'll be able to spot

docs/management/replication.md

@@ -148,8 +148,7 @@ Normally a full resynchronization requires creating an RDB file on disk,
 then reloading the same RDB from disk to feed the replicas with the data.
 
 With slow disks this can be a very stressing operation for the master.
-Redis version 2.8.18 is the first version to have support for diskless
-replication. In this setup the child process directly sends the
+In this setup the child process directly sends the
 RDB over the wire to replicas, without using the disk as intermediate storage.
 
 ## Configuration

docs/management/sentinel.md

@@ -639,7 +639,7 @@ Lastly, Sentinel also supports the `SUBSCRIBE`, `UNSUBSCRIBE`, `PSUBSCRIBE` and
 
 ### Reconfiguring Sentinel at Runtime
 
-Starting with Redis version 2.8.4, Sentinel provides an API in order to add, remove, or change the configuration of a given master. Note that if you have multiple sentinels you should apply the changes to all to your instances for Redis Sentinel to work properly. This means that changing the configuration of a single Sentinel does not automatically propagate the changes to the other Sentinels in the network.
+Sentinel provides an API in order to add, remove, or change the configuration of a given master. Note that if you have multiple sentinels you should apply the changes to all to your instances for Redis Sentinel to work properly. This means that changing the configuration of a single Sentinel does not automatically propagate the changes to the other Sentinels in the network.
 
 The following is a list of `SENTINEL` subcommands used in order to update the configuration of a Sentinel instance.
 
@@ -657,7 +657,7 @@ As already stated, `SENTINEL SET` can be used to set all the configuration param
 
 Note that there is no equivalent GET command since `SENTINEL MASTER` provides all the configuration parameters in a simple to parse format (as a field/value pairs array).
 
-Starting with Redis version 6.2, Sentinel also allows getting and setting global configuration parameters which were only supported in the configuration file prior to that.
+Sentinel also allows getting and setting global configuration parameters which were only supported in the configuration file prior to that.
 
 * **SENTINEL CONFIG GET `<name>`** Get the current value of a global Sentinel configuration parameter. The specified name may be a wildcard, similar to the Redis `CONFIG GET` command.
 * **SENTINEL CONFIG SET `<name>` `<value>`** Set the value of a global Sentinel configuration parameter.