Changed links and naming to valkey instead of redis

00-RELEASENOTES

@@ -1,5 +1,5 @@
 Hello! This file is just a placeholder, since this is the "unstable" branch
-of Redis, the place where all the development happens.
+of Valkey, the place where all the development happens.
 
 There is no release notes for this branch, it gets forked into another branch
 every time there is a partial feature freeze in order to eventually create
@@ -9,8 +9,8 @@ Usually "unstable" is stable enough for you to use it in development environment
 however you should never use it in production environments. It is possible
 to download the latest stable release here:
 
-    https://download.redis.io/redis-stable.tar.gz
+    https://github.com/valkey-io/valkey/releases
 
-More information is available at https://redis.io
+More information is available at https://valkey.io
 
 Happy hacking!

COPYING

@@ -20,6 +20,6 @@ Redistribution and use in source and binary forms, with or without modification,
 
     * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
     * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
-    * Neither the name of Redis nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
+    * Neither the name of Valkey nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
 
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

MANIFESTO

@@ -1,62 +1,62 @@
-[Note: this is the Redis manifesto, for general information about
-       installing and running Redis read the README file instead.]
+[Note: this is the Valkey manifesto, for general information about
+       installing and running Valkey read the README file instead.]
 
-Redis Manifesto
+Valkey Manifesto
 ===============
 
-1 - A DSL for Abstract Data Types. Redis is a DSL (Domain Specific Language)
+1 - A DSL for Abstract Data Types. Valkey is a DSL (Domain Specific Language)
     that manipulates abstract data types and implemented as a TCP daemon.
     Commands manipulate a key space where keys are binary-safe strings and
     values are different kinds of abstract data types. Every data type
     represents an abstract version of a fundamental data structure. For instance
-    Redis Lists are an abstract representation of linked lists. In Redis, the
+    Valkey Lists are an abstract representation of linked lists. In Valkey, the
     essence of a data type isn't just the kind of operations that the data types
     support, but also the space and time complexity of the data type and the
     operations performed upon it.
 
-2 - Memory storage is #1. The Redis data set, composed of defined key-value
+2 - Memory storage is #1. The Valkey data set, composed of defined key-value
     pairs, is primarily stored in the computer's memory. The amount of memory in
     all kinds of computers, including entry-level servers, is increasing
-    significantly each year. Memory is fast, and allows Redis to have very
+    significantly each year. Memory is fast, and allows Valkey to have very
     predictable performance. Datasets composed of 10k or 40 millions keys will
-    perform similarly. Complex data types like Redis Sorted Sets are easy to
-    implement and manipulate in memory with good performance, making Redis very
-    simple. Redis will continue to explore alternative options (where data can
+    perform similarly. Complex data types like Valkey Sorted Sets are easy to
+    implement and manipulate in memory with good performance, making Valkey very
+    simple. Valkey will continue to explore alternative options (where data can
     be optionally stored on disk, say) but the main goal of the project remains
     the development of an in-memory database.
 
-3 - Fundamental data structures for a fundamental API. The Redis API is a direct
+3 - Fundamental data structures for a fundamental API. The Valkey API is a direct
     consequence of fundamental data structures. APIs can often be arbitrary but
     not an API that resembles the nature of fundamental data structures. If we
     ever meet intelligent life forms from another part of the universe, they'll
     likely know, understand and recognize the same basic data structures we have
-    in our computer science books. Redis will avoid intermediate layers in API,
+    in our computer science books. Valkey will avoid intermediate layers in API,
     so that the complexity is obvious and more complex operations can be
     performed as the sum of the basic operations.
 
 4 - We believe in code efficiency. Computers get faster and faster, yet we
     believe that abusing computing capabilities is not wise: the amount of
     operations you can do for a given amount of energy remains anyway a
     significant parameter: it allows to do more with less computers and, at
-    the same time, having a smaller environmental impact. Similarly Redis is
+    the same time, having a smaller environmental impact. Similarly Valkey is
     able to "scale down" to smaller devices. It is perfectly usable in a
     Raspberry Pi and other small ARM based computers. Faster code having
     just the layers of abstractions that are really needed will also result,
     often, in more predictable performances. We think likewise about memory
-    usage, one of the fundamental goals of the Redis project is to
+    usage, one of the fundamental goals of the Valkey project is to
     incrementally build more and more memory efficient data structures, so that
     problems that were not approachable in RAM in the past will be perfectly
     fine to handle in the future.
 
 5 - Code is like a poem; it's not just something we write to reach some
-    practical result. Sometimes people that are far from the Redis philosophy
+    practical result. Sometimes people that are far from the Valkey philosophy
     suggest using other code written by other authors (frequently in other
-    languages) in order to implement something Redis currently lacks. But to us
+    languages) in order to implement something Valkey currently lacks. But to us
     this is like if Shakespeare decided to end Enrico IV using the Paradiso from
     the Divina Commedia. Is using any external code a bad idea? Not at all. Like
     in "One Thousand and One Nights" smaller self contained stories are embedded
     in a bigger story, we'll be happy to use beautiful self contained libraries
-    when needed. At the same time, when writing the Redis story we're trying to
+    when needed. At the same time, when writing the Valkey story we're trying to
     write smaller stories that will fit in to other code.
 
 6 - We're against complexity. We believe designing systems is a fight against
@@ -65,25 +65,25 @@ Redis Manifesto
     of code. Most of the time the best way to fight complexity is by not
     creating it at all. Complexity is also a form of lock-in: code that is
     very hard to understand cannot be modified by users in an independent way
-    regardless of the license. One of the main Redis goals is to remain
+    regardless of the license. One of the main Valkey goals is to remain
     understandable, enough for a single programmer to have a clear idea of how
     it works in detail just reading the source code for a couple of weeks.
 
-7 - Threading is not a silver bullet. Instead of making Redis threaded we
-    believe on the idea of an efficient (mostly) single threaded Redis core.
+7 - Threading is not a silver bullet. Instead of making Valkey threaded we
+    believe on the idea of an efficient (mostly) single threaded Valkey core.
     Multiple of such cores, that may run in the same computer or may run
     in multiple computers, are abstracted away as a single big system by
-    higher order protocols and features: Redis Cluster and the upcoming
-    Redis Proxy are our main goals. A shared nothing approach is not just
+    higher order protocols and features: Valkey Cluster and the upcoming
+    Valkey Proxy are our main goals. A shared nothing approach is not just
     much simpler (see the previous point in this document), is also optimal
-    in NUMA systems. In the specific case of Redis it allows for each instance
-    to have a more limited amount of data, making the Redis persist-by-fork
+    in NUMA systems. In the specific case of Valkey it allows for each instance
+    to have a more limited amount of data, making the Valkey persist-by-fork
     approach more sounding. In the future we may explore parallelism only for
     I/O, which is the low hanging fruit: minimal complexity could provide an
     improved single process experience.
 
-8 - Two levels of API. The Redis API has two levels: 1) a subset of the API fits
-    naturally into a distributed version of Redis and 2) a more complex API that
+8 - Two levels of API. The Valkey API has two levels: 1) a subset of the API fits
+    naturally into a distributed version of Valkey and 2) a more complex API that
     supports multi-key operations. Both are useful if used judiciously but
     there's no way to make the more complex multi-keys API distributed in an
     opaque way without violating our other principles. We don't want to provide
@@ -95,12 +95,12 @@ Redis Manifesto
 9 - We optimize for joy. We believe writing code is a lot of hard work, and the
     only way it can be worth is by enjoying it. When there is no longer joy in
     writing code, the best thing to do is stop. To prevent this, we'll avoid
-    taking paths that will make Redis less of a joy to develop.
+    taking paths that will make Valkey less of a joy to develop.
 
 10 - All the above points are put together in what we call opportunistic
      programming: trying to get the most for the user with minimal increases
      in complexity (hanging fruits). Solve 95% of the problem with 5% of the
      code when it is acceptable. Avoid a fixed schedule but follow the flow of
-     user requests, inspiration, Redis internal readiness for certain features
+     user requests, inspiration, Valkey internal readiness for certain features
      (sometimes many past changes reach a critical point making a previously
      complex feature very easy to obtain).

README.md

@@ -2,7 +2,7 @@
 
 This README is under construction as we work to build a new community driven high performance key-value store.
 
-This project was forked from the open source Redis project right before the transition to their new source available licenses.
+This project was forked from the open source Valkey project right before the transition to their new source available licenses.
 
 This README is just a fast *quick start* document. We are currently working on a more permanent documentation page.
 
@@ -185,7 +185,7 @@ In order to install Valkey binaries into /usr/local/bin, just use:
 You can use `make PREFIX=/some/other/directory install` if you wish to use a
 different destination.
 
-_Note_: For compatibility with Redis, we create symlinks from the Redis names (`redis-server`, `redis-cli`, etc.) to the Valkey binaries installed by `make install`.
+_Note_: For compatibility with Valkey, we create symlinks from the Valkey names (`redis-server`, `valkey-cli`, etc.) to the Valkey binaries installed by `make install`.
 The symlinks are created in same directory as the Valkey binaries.
 The symlinks are removed when using `make uninstall`.
 The creation of the symlinks can be skipped by setting the makefile variable `USE_REDIS_SYMLINKS=no`.

deps/README.md

@@ -1,9 +1,9 @@
-This directory contains all Redis dependencies, except for the libc that
+This directory contains all Valkey dependencies, except for the libc that
 should be provided by the operating system.
 
 * **Jemalloc** is our memory allocator, used as replacement for libc malloc on Linux by default. It has good performances and excellent fragmentation behavior. This component is upgraded from time to time.
-* **hiredis** is the official C client library for Redis. It is used by redis-cli, redis-benchmark and Redis Sentinel. It is part of the Redis official ecosystem but is developed externally from the Redis repository, so we just upgrade it as needed.
-* **linenoise** is a readline replacement. It is developed by the same authors of Redis but is managed as a separated project and updated as needed.
+* **hiredis** is the official C client library for Valkey. It is used by valkey-cli, redis-benchmark and Valkey Sentinel. It is part of the Valkey official ecosystem but is developed externally from the Valkey repository, so we just upgrade it as needed.
+* **linenoise** is a readline replacement. It is developed by the same authors of Valkey but is managed as a separated project and updated as needed.
 * **lua** is Lua 5.1 with minor changes for security and additional libraries.
 * **hdr_histogram** Used for per-command latency tracking histograms.
 
@@ -13,10 +13,10 @@ How to upgrade the above dependencies
 Jemalloc
 ---
 
-Jemalloc is modified with changes that allow us to implement the Redis
-active defragmentation logic. However this feature of Redis is not mandatory
-and Redis is able to understand if the Jemalloc version it is compiled
-against supports such Redis-specific modifications. So in theory, if you
+Jemalloc is modified with changes that allow us to implement the Valkey
+active defragmentation logic. However this feature of Valkey is not mandatory
+and Valkey is able to understand if the Jemalloc version it is compiled
+against supports such Valkey-specific modifications. So in theory, if you
 are not interested in the active defragmentation, you can replace Jemalloc
 just following these steps:
 
@@ -28,7 +28,7 @@ just following these steps:
    Jemalloc configuration script is broken and will not work nested in another
    git repository.
 
-However note that we change Jemalloc settings via the `configure` script of Jemalloc using the `--with-lg-quantum` option, setting it to the value of 3 instead of 4. This provides us with more size classes that better suit the Redis data structures, in order to gain memory efficiency.
+However note that we change Jemalloc settings via the `configure` script of Jemalloc using the `--with-lg-quantum` option, setting it to the value of 3 instead of 4. This provides us with more size classes that better suit the Valkey data structures, in order to gain memory efficiency.
 
 If you want to upgrade Jemalloc while also providing support for
 active defragmentation, in addition to the above steps you need to perform
@@ -38,7 +38,7 @@ the following additional steps:
    to add `#define JEMALLOC_FRAG_HINT`.
 6. Implement the function `je_get_defrag_hint()` inside `src/jemalloc.c`. You
    can see how it is implemented in the current Jemalloc source tree shipped
-   with Redis, and rewrite it according to the new Jemalloc internals, if they
+   with Valkey, and rewrite it according to the new Jemalloc internals, if they
    changed, otherwise you could just copy the old implementation if you are
    upgrading just to a similar version of Jemalloc.
 
@@ -61,7 +61,7 @@ cd deps/jemalloc
 Hiredis
 ---
 
-Hiredis is used by Sentinel, `redis-cli` and `redis-benchmark`. Like Redis, uses the SDS string library, but not necessarily the same version. In order to avoid conflicts, this version has all SDS identifiers prefixed by `hi`.
+Hiredis is used by Sentinel, `valkey-cli` and `redis-benchmark`. Like Valkey, uses the SDS string library, but not necessarily the same version. In order to avoid conflicts, this version has all SDS identifiers prefixed by `hi`.
 
 1. `git subtree pull --prefix deps/hiredis https://github.com/redis/hiredis.git <version-tag> --squash`<br>
 This should hopefully merge the local changes into the new version.
@@ -71,7 +71,7 @@ Linenoise
 ---
 
 Linenoise is rarely upgraded as needed. The upgrade process is trivial since
-Redis uses a non modified version of linenoise, so to upgrade just do the
+Valkey uses a non modified version of linenoise, so to upgrade just do the
 following:
 
 1. Remove the linenoise directory.
@@ -81,11 +81,11 @@ Lua
 ---
 
 We use Lua 5.1 and no upgrade is planned currently, since we don't want to break
-Lua scripts for new Lua features: in the context of Redis Lua scripts the
+Lua scripts for new Lua features: in the context of Valkey Lua scripts the
 capabilities of 5.1 are usually more than enough, the release is rock solid,
 and we definitely don't want to break old scripts.
 
-So upgrading of Lua is up to the Redis project maintainers and should be a
+So upgrading of Lua is up to the Valkey project maintainers and should be a
 manual procedure performed by taking a diff between the different versions.
 
 Currently we have at least the following differences between official Lua 5.1

deps/hiredis/COPYING

@@ -13,7 +13,7 @@ modification, are permitted provided that the following conditions are met:
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.
 
-* Neither the name of Redis nor the names of its contributors may be used
+* Neither the name of Valkey nor the names of its contributors may be used
   to endorse or promote products derived from this software without specific
   prior written permission.
 

deps/linenoise/README.markdown

@@ -17,7 +17,7 @@ Line editing with some support for history is a really important feature for com
 So what usually happens is either:
 
  * Large programs with configure scripts disabling line editing if readline is not present in the system, or not supporting it at all since readline is GPL licensed and libedit (the BSD clone) is not as known and available as readline is (Real world example of this problem: Tclsh).
- * Smaller programs not using a configure script not supporting line editing at all (A problem we had with Redis-cli for instance).
+ * Smaller programs not using a configure script not supporting line editing at all (A problem we had with Valkey-cli for instance).
 
 The result is a pollution of binaries without line editing support.
 

src/commands/README.md

@@ -2,7 +2,7 @@ This directory contains JSON files, one for each command.
 
 Each JSON contains all the information about the command itself, but these JSON files are not to be used directly!
 Any third party who needs access to command information must get it from `COMMAND INFO` and `COMMAND DOCS`.
-The output can be extracted in a JSON format by using `redis-cli --json`, in the same manner as in `utils/generate-commands-json.py`.
+The output can be extracted in a JSON format by using `valkey-cli --json`, in the same manner as in `utils/generate-commands-json.py`.
 
 The JSON files are used to generate commands.def within this repo and JSON files for documentation, and
 despite looking similar to the output of `COMMAND` there are some fields and flags that are implicitly populated, and that's the