From 829f0296d0141339284f28c1cf62032a47c6cd47 Mon Sep 17 00:00:00 2001 From: Madelyn Olson Date: Thu, 23 May 2024 15:32:48 -0700 Subject: [PATCH 1/7] Update release guidance for Valkey Signed-off-by: Madelyn Olson --- topics/releases.md | 160 ++++++++++++++++----------------------------- 1 file changed, 57 insertions(+), 103 deletions(-) diff --git a/topics/releases.md b/topics/releases.md index b2ed3041..32b55784 100644 --- a/topics/releases.md +++ b/topics/releases.md @@ -1,144 +1,98 @@ --- -title: "Valkey release cycle" -linkTitle: "Release cycle" +title: "Valkey releases and versioning" +linkTitle: "Valkey releases" weight: 4 -description: How are new versions of Valkey released? +description: How new versions of Valkey released and supported aliases: - /topics/releases --- -Valkey is system software and a type of system software that holds user data, so -it is among the most critical pieces of a software stack. +Valkey is usually among the most critical pieces of a software stack. +For this reason, Valkey's release cycle prioritizes highly stable releases at the cost of slower release cycles. -For this reason, Valkey's release cycle is such that it ensures highly stable -releases, even at the cost of slower cycles. - -New releases are published in the [Valkey GitHub repository](https://github.com/valkey-io/valkey/releases). - -## Release cycle - -A given version of Valkey can be at three different levels of stability: - -* Unstable -* Release Candidate -* Stable - -### Unstable tree - -The unstable version of Valkey is located in the `unstable` branch in the -[Valkey GitHub repository](https://github.com/valkey-io/valkey). - -This branch is the source tree where most of the new features are under -development. `unstable` is not considered production-ready: it may contain -critical bugs, incomplete features, and is potentially unstable. - -However, we try hard to make sure that even the unstable branch is usable most -of the time in a development environment without significant issues. - -### Release candidate - -New minor and major versions of Valkey begin by branching off the `unstable` -branch. The branch name is the target release on the form *major.minor*. -Subsequent patch releases are made on the same branch. - -For example, when Valkey 7.2.5 was released, the release was made on the `7.2` -branch, which had been branched off from `unstable` earlier. - -Bug fixes and new features that can be stabilized during the release's time -frame are committed to the unstable branch and backported to the release -candidate branch. The `unstable` branch may include additional work that is not -a part of the release candidate and scheduled for future releases. - -The first release candidate, or RC1, is released once it can be used for -development purposes and for testing the new version. At this stage, most of -the new features and changes the new version brings are ready for review, and -the release's purpose is collecting the public's feedback. - -Subsequent release candidates are released every three weeks or so, primarily -for fixing bugs. These may also add new features and introduce changes, but at -a decreasing rate and decreasing potential risk towards the final release -candidate. - -### Stable tree - -Once development has ended and the frequency of critical bug reports for the -release candidate wanes, it is ready for the final release. At this point, the -release is marked as stable and is released with "0" as its patch-level -version. +All Valkey releases are published in the [Valkey GitHub repository](https://github.com/valkey-io/valkey/releases). ## Versioning -Stable releases liberally follow the usual `major.minor.patch` semantic -versioning schema. The primary goal is to provide explicit guarantees regarding -backward compatibility. +Valkey stable releases will follow generally `major.minor.patch` [semantic versioning schema](https://semver.org/). +We follow semantic versioning to provide explicit guarantees regarding backward compatibility. -### Patch-Level versions +### Patch versions -Patches primarily consist of bug fixes and very rarely introduce any -compatibility issues. +PATCH versions are released with backwards compatible bug fixes and should not introduce new features. -Upgrading from a previous patch-level version is almost always safe and -seamless. +Upgrading from a previous patch version should be safe and seamless. +It should be safe to run a Valkey cluster with servers running on different patch versions. -New features and configuration directives may be added, or default values -changed, as long as these don’t carry significant impacts or introduce -operations-related issues. +PATCH versions may also introduce small improvements such as performance or memory optimizations that don't come with any tradeoffs. ### Minor versions -Minor versions usually deliver maturity and extended functionality. +MINOR version are released with new functionality that is added in a backward compatible manner. +Examples of new functionality include new commands, info fields, or configuration parameters. + +Upgrading from a previous minor version should be safe, and will not introduce incompatibilities between servers in the cluster. -Upgrading between minor versions does not introduce any application-level -compatibility issues. +**NOTE:** Minor releases may include new commands and data types that can introduce incompatibility between servers in the cluster, but users need to opt-in to these features to cause this type of incompatibility. +For this reason, it is not recommended to run a Valkey cluster with servers running on different minor versions. +Users should also avoid new features until all servers in the cluster have been upgrades. -Minor releases may include new commands and data types that introduce -operations-related incompatibilities, including changes in data persistence -format and replication protocol. +Commands may also be deprecated in minor versions. +If a command is deprecated, a replacement command or an alternative to using the command will be defined in the same minor version. ### Major versions -Major versions introduce new capabilities and significant changes. +MAJOR versions are released with significant functionality that may break backwards compatibility or alter key performance characteristics. +Examples of significant functionality include altering the behavior of an existing command, removing previously deprecated commands, changing the default value of configs, and significant refactoring for performance improvements. -Ideally, these don't introduce application-level compatibility issues. +Upgrading from a previous major version is intended to be safe, but should be approached with caution. +You should carefully read the release notes before performing a major version upgrade. +Major version upgrades do not guarantee backwards compatibility, which means you should always upgrade replicas before upgrading primaries in order to ensure data consistency. + +The Valkey community strives to make as few backwards breaking changes as possible. +When breaking changes are required, we will also strive to provide a way to mitigate the impact without incuring downtime to your application. ## Release schedule -A new major version is planned for release once a year. +The Valkey community strives to release a stable major version once a year. +Stable minor versions are created as needed in between major releases, and we aim to release at least one minor version a year. -Generally, every major release is followed by a minor version after six months. +### Release candidate -Patches are released as needed to fix high-urgency issues, or once a stable -version accumulates enough fixes to justify it. +New minor and major versions of Valkey begin by branching off the `unstable` branch as an initial release candidate branch, which take the form *major.minor.patch-R#*. +The first release candidate, or RC1, is released once it can be used for development purposes and for testing the new version. +At this stage, most of the new features and changes in the new version are ready for review, and the version is released for the purpose of collecting the public's feedback. +Subsequent release candidates are released every coupe of weeks, primarily for fixing bugs and refining features based off of user input. -For contacting the core team on sensitive matters and security issues, please -see [SECURITY.md](https://github.com/valkey-io/valkey/blob/unstable/SECURITY.md). +### Stable release -## Support +Once development has ended and the feedback for release candidate slows down, it is ready for the final release. +At this point, the release is marked as stable and is released with "0" as its patch-level version. -As a rule, older versions are not supported as we try very hard to make the -API mostly backward compatible. +Patches are released as needed to fix high-urgency issues, or once a stable version accumulates enough fixes to justify it. -Upgrading to newer versions is the recommended approach and is usually trivial. +## Support The latest stable release is always fully supported and maintained. -Two additional versions receive maintenance only, meaning that only fixes for -critical bugs and major security issues are committed and released as patches: +The Valkey community will provide maintanence support, providing patch releases for bug fixes and all security fixes, for 3 years from when a version was first released. + +The Valkey community will also provide extended security security support for the latest minor version of each major version for 5 years from when a version was first released. +The Valkey community will only backport security issues we believe to be possible to exploit, which will be up to the discretion of the TSC. + +For contacting the core team on sensitive matters and security issues, please see [SECURITY.md](https://github.com/valkey-io/valkey/blob/unstable/SECURITY.md). -* The previous minor version of the latest stable release. -* The previous stable major release. - -For example, consider the following hypothetical versions: 1.2, 2.0, 2.2, 3.0, -3.2. +### List of supported versions -When version 2.2 is the latest stable release, both 2.0 and 1.2 are maintained. +| Version | Initial release | Maintenence support end | Extended Security support end | +| -- | -- | -- | -- | +| 7.2 | 2024-04-16 | 2027-04-16 | 2029-04-16 | -Once version 3.0.0 replaces 2.2 as the latest stable, versions 2.0 and 2.2 are -maintained, whereas version 1.x reaches its end of life. +## Unstable tree -This process repeats with version 3.2.0, after which only versions 2.2 and 3.0 -are maintained. +The unstable development tree of Valkey is located in the `unstable` branch in the [Valkey GitHub repository](https://github.com/valkey-io/valkey). -The above are guidelines rather than rules set in stone and will not replace -common sense. +This branch is the source tree where most of the new features are under development. +`unstable` is not considered production-ready: it may contain critical bugs, incomplete features, and is potentially unstable. +However, we try hard to make sure that even the unstable branch is usable most of the time in a development environment without significant issues. \ No newline at end of file From 9deb7c7892ccd64003eb40464a397669d214ee3e Mon Sep 17 00:00:00 2001 From: Madelyn Olson Date: Mon, 17 Jun 2024 20:21:59 -0700 Subject: [PATCH 2/7] Addressed most comments Signed-off-by: Madelyn Olson --- topics/releases.md | 37 ++++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/topics/releases.md b/topics/releases.md index 32b55784..673a9395 100644 --- a/topics/releases.md +++ b/topics/releases.md @@ -2,7 +2,7 @@ title: "Valkey releases and versioning" linkTitle: "Valkey releases" weight: 4 -description: How new versions of Valkey released and supported +description: How new versions of Valkey are released and supported aliases: - /topics/releases --- @@ -14,36 +14,45 @@ All Valkey releases are published in the [Valkey GitHub repository](https://gith ## Versioning -Valkey stable releases will follow generally `major.minor.patch` [semantic versioning schema](https://semver.org/). +Valkey stable releases will generally follow `major.minor.patch` [semantic versioning schema](https://semver.org/). We follow semantic versioning to provide explicit guarantees regarding backward compatibility. +When discussing compatibility, we refer to the following API contracts: + +1. Valkey commands including their inputs, outputs, and defined behavior +2. The functions and APIs that can be executed from a Lua script +3. The RDB version +4. The protocol used to establish and replicate data from primaries to replicas +5. The protocol between nodes within a Valkey cluster +6. The Valkey Module API interface + ### Patch versions -PATCH versions are released with backwards compatible bug fixes and should not introduce new features. +*Patch* versions are released with backwards compatible bug fixes and should not introduce new features. Upgrading from a previous patch version should be safe and seamless. It should be safe to run a Valkey cluster with servers running on different patch versions. -PATCH versions may also introduce small improvements such as performance or memory optimizations that don't come with any tradeoffs. +*Patch* versions may also introduce small improvements such as performance or memory optimizations that are easy to verify as safe. ### Minor versions -MINOR version are released with new functionality that is added in a backward compatible manner. +*Minor* versions are released with new functionality that is added in a backward compatible manner. Examples of new functionality include new commands, info fields, or configuration parameters. Upgrading from a previous minor version should be safe, and will not introduce incompatibilities between servers in the cluster. **NOTE:** Minor releases may include new commands and data types that can introduce incompatibility between servers in the cluster, but users need to opt-in to these features to cause this type of incompatibility. For this reason, it is not recommended to run a Valkey cluster with servers running on different minor versions. -Users should also avoid new features until all servers in the cluster have been upgrades. +Users should avoid new features until all servers in the cluster have been upgraded. Commands may also be deprecated in minor versions. If a command is deprecated, a replacement command or an alternative to using the command will be defined in the same minor version. ### Major versions -MAJOR versions are released with significant functionality that may break backwards compatibility or alter key performance characteristics. -Examples of significant functionality include altering the behavior of an existing command, removing previously deprecated commands, changing the default value of configs, and significant refactoring for performance improvements. +*Major* versions are released with significant functionality that may break backwards compatibility or alter key performance characteristics. +Examples of significant functionality includes altering the behavior of an existing command, removing previously deprecated commands, changing the default value of configs, and significant refactoring for performance improvements. Upgrading from a previous major version is intended to be safe, but should be approached with caution. You should carefully read the release notes before performing a major version upgrade. @@ -59,10 +68,11 @@ Stable minor versions are created as needed in between major releases, and we ai ### Release candidate -New minor and major versions of Valkey begin by branching off the `unstable` branch as an initial release candidate branch, which take the form *major.minor.patch-R#*. -The first release candidate, or RC1, is released once it can be used for development purposes and for testing the new version. +New minor and major versions of Valkey begin by branching off the `unstable` branch as an initial release candidate branch with a name that takes the form of `*major.minor*`, example `7.2`. +The first release candidate, or rc1, is released once it can be used for development purposes and for testing the new version. +Release candidate versions will start with a patch version of "0" and will take the form `*major.minor.patch-rcN*`, example `7.2.0-rc1` followed by `7.2.0-rc2`. At this stage, most of the new features and changes in the new version are ready for review, and the version is released for the purpose of collecting the public's feedback. -Subsequent release candidates are released every coupe of weeks, primarily for fixing bugs and refining features based off of user input. +Subsequent release candidates are released every couple of weeks, primarily for fixing bugs and refining features based off of user input. ### Stable release @@ -78,9 +88,10 @@ The latest stable release is always fully supported and maintained. The Valkey community will provide maintanence support, providing patch releases for bug fixes and all security fixes, for 3 years from when a version was first released. The Valkey community will also provide extended security security support for the latest minor version of each major version for 5 years from when a version was first released. +The minor version to be used for this extended security support will be decided once the next major version has been launched. The Valkey community will only backport security issues we believe to be possible to exploit, which will be up to the discretion of the TSC. -For contacting the core team on sensitive matters and security issues, please see [SECURITY.md](https://github.com/valkey-io/valkey/blob/unstable/SECURITY.md). +For contacting the TSC on sensitive matters and security issues, please see [SECURITY.md](https://github.com/valkey-io/valkey/blob/unstable/SECURITY.md). ### List of supported versions @@ -90,7 +101,7 @@ For contacting the core team on sensitive matters and security issues, please se ## Unstable tree -The unstable development tree of Valkey is located in the `unstable` branch in the [Valkey GitHub repository](https://github.com/valkey-io/valkey). +The development tree of Valkey is located in the `unstable` branch in the [Valkey GitHub repository](https://github.com/valkey-io/valkey). This branch is the source tree where most of the new features are under development. `unstable` is not considered production-ready: it may contain critical bugs, incomplete features, and is potentially unstable. From 5352f3aab16db5e76cf13d9eafd5b25558bf0267 Mon Sep 17 00:00:00 2001 From: Madelyn Olson Date: Mon, 17 Jun 2024 21:18:54 -0700 Subject: [PATCH 3/7] Fixed spelling issues Signed-off-by: Madelyn Olson --- topics/releases.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/topics/releases.md b/topics/releases.md index 673a9395..75d37ae6 100644 --- a/topics/releases.md +++ b/topics/releases.md @@ -59,7 +59,7 @@ You should carefully read the release notes before performing a major version up Major version upgrades do not guarantee backwards compatibility, which means you should always upgrade replicas before upgrading primaries in order to ensure data consistency. The Valkey community strives to make as few backwards breaking changes as possible. -When breaking changes are required, we will also strive to provide a way to mitigate the impact without incuring downtime to your application. +When breaking changes are required, we will also strive to provide a way to mitigate the impact without incurring downtime to your application. ## Release schedule @@ -85,17 +85,17 @@ Patches are released as needed to fix high-urgency issues, or once a stable vers The latest stable release is always fully supported and maintained. -The Valkey community will provide maintanence support, providing patch releases for bug fixes and all security fixes, for 3 years from when a version was first released. +The Valkey community will provide maintenance support, providing patch releases for bug fixes and all security fixes, for 3 years from when a version was first released. The Valkey community will also provide extended security security support for the latest minor version of each major version for 5 years from when a version was first released. The minor version to be used for this extended security support will be decided once the next major version has been launched. -The Valkey community will only backport security issues we believe to be possible to exploit, which will be up to the discretion of the TSC. +The Valkey community will only patch security issues we believe to be possible to exploit, which will be up to the discretion of the TSC. For contacting the TSC on sensitive matters and security issues, please see [SECURITY.md](https://github.com/valkey-io/valkey/blob/unstable/SECURITY.md). ### List of supported versions -| Version | Initial release | Maintenence support end | Extended Security support end | +| Version | Initial release | Maintenance support end | Extended Security support end | | -- | -- | -- | -- | | 7.2 | 2024-04-16 | 2027-04-16 | 2029-04-16 | From 19e4ca3d0b967d57a4db7f5ab0157a6ba04068da Mon Sep 17 00:00:00 2001 From: Madelyn Olson Date: Mon, 17 Jun 2024 21:50:48 -0700 Subject: [PATCH 4/7] Attempt to address Ping's comments Signed-off-by: Madelyn Olson --- topics/releases.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/topics/releases.md b/topics/releases.md index 75d37ae6..fd586f71 100644 --- a/topics/releases.md +++ b/topics/releases.md @@ -25,6 +25,7 @@ When discussing compatibility, we refer to the following API contracts: 4. The protocol used to establish and replicate data from primaries to replicas 5. The protocol between nodes within a Valkey cluster 6. The Valkey Module API interface +7. The AOF on disk format ### Patch versions @@ -40,23 +41,23 @@ It should be safe to run a Valkey cluster with servers running on different patc *Minor* versions are released with new functionality that is added in a backward compatible manner. Examples of new functionality include new commands, info fields, or configuration parameters. -Upgrading from a previous minor version should be safe, and will not introduce incompatibilities between servers in the cluster. +Upgrading from a previous minor version should be safe, and will not introduce incompatibilities between servers in the cluster when default server configurations are used. **NOTE:** Minor releases may include new commands and data types that can introduce incompatibility between servers in the cluster, but users need to opt-in to these features to cause this type of incompatibility. For this reason, it is not recommended to run a Valkey cluster with servers running on different minor versions. Users should avoid new features until all servers in the cluster have been upgraded. -Commands may also be deprecated in minor versions. -If a command is deprecated, a replacement command or an alternative to using the command will be defined in the same minor version. +Commands may also be marked as **deprecated** in minor versions. +Deprecated commands are not removed, instead a replacement command or an alternative to using the command will be defined in the same minor version. ### Major versions *Major* versions are released with significant functionality that may break backwards compatibility or alter key performance characteristics. Examples of significant functionality includes altering the behavior of an existing command, removing previously deprecated commands, changing the default value of configs, and significant refactoring for performance improvements. -Upgrading from a previous major version is intended to be safe, but should be approached with caution. +Upgrading from a previous major version is intended to be safe, but should be approached with caution. You should carefully read the release notes before performing a major version upgrade. -Major version upgrades do not guarantee backwards compatibility, which means you should always upgrade replicas before upgrading primaries in order to ensure data consistency. +Major version upgrades only guarantee backwards compatibility, which means you should always upgrade replicas before upgrading primaries in order to ensure data consistency. The Valkey community strives to make as few backwards breaking changes as possible. When breaking changes are required, we will also strive to provide a way to mitigate the impact without incurring downtime to your application. @@ -71,12 +72,12 @@ Stable minor versions are created as needed in between major releases, and we ai New minor and major versions of Valkey begin by branching off the `unstable` branch as an initial release candidate branch with a name that takes the form of `*major.minor*`, example `7.2`. The first release candidate, or rc1, is released once it can be used for development purposes and for testing the new version. Release candidate versions will start with a patch version of "0" and will take the form `*major.minor.patch-rcN*`, example `7.2.0-rc1` followed by `7.2.0-rc2`. -At this stage, most of the new features and changes in the new version are ready for review, and the version is released for the purpose of collecting the public's feedback. +At this stage, most of the new features and changes in the new version are ready for review, and the version is released for the purpose of collecting public feedback. Subsequent release candidates are released every couple of weeks, primarily for fixing bugs and refining features based off of user input. ### Stable release -Once development has ended and the feedback for release candidate slows down, it is ready for the final release. +Once development has ended and the feedback for release candidate slows down, it is ready for the final release. At this point, the release is marked as stable and is released with "0" as its patch-level version. Patches are released as needed to fix high-urgency issues, or once a stable version accumulates enough fixes to justify it. @@ -85,9 +86,9 @@ Patches are released as needed to fix high-urgency issues, or once a stable vers The latest stable release is always fully supported and maintained. -The Valkey community will provide maintenance support, providing patch releases for bug fixes and all security fixes, for 3 years from when a version was first released. +The Valkey community will provide maintenance support, providing patch releases for bug fixes and all security fixes, for 3 years from when a minor version was first released. -The Valkey community will also provide extended security security support for the latest minor version of each major version for 5 years from when a version was first released. +The Valkey community will also provide extended security support for the latest minor version of each major version for 5 years from when a version was first released. The minor version to be used for this extended security support will be decided once the next major version has been launched. The Valkey community will only patch security issues we believe to be possible to exploit, which will be up to the discretion of the TSC. From 58519e05eede8eeeeee28c7c79001fb76b91cfaf Mon Sep 17 00:00:00 2001 From: Madelyn Olson Date: Mon, 17 Jun 2024 22:01:53 -0700 Subject: [PATCH 5/7] Make an opinion about replication compatibility Signed-off-by: Madelyn Olson --- topics/releases.md | 3 ++- wordlist | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/topics/releases.md b/topics/releases.md index fd586f71..ee8d1fcb 100644 --- a/topics/releases.md +++ b/topics/releases.md @@ -57,7 +57,8 @@ Examples of significant functionality includes altering the behavior of an exist Upgrading from a previous major version is intended to be safe, but should be approached with caution. You should carefully read the release notes before performing a major version upgrade. -Major version upgrades only guarantee backwards compatibility, which means you should always upgrade replicas before upgrading primaries in order to ensure data consistency. +Although Major versions can introduce breaking changes, data replicated from primaries to replicas will always be sent in a backward compatible format. +You should always upgrade replicas before upgrading primaries in order to ensure data consistency. The Valkey community strives to make as few backwards breaking changes as possible. When breaking changes are required, we will also strive to provide a way to mitigate the impact without incurring downtime to your application. diff --git a/wordlist b/wordlist index 44bae967..3b307917 100644 --- a/wordlist +++ b/wordlist @@ -742,6 +742,7 @@ race:italy race:usa radix rc +rc1 RC1 RC3 RC4 From 7c095e7a6b052ecca3877f9898aa0afabf4c5af4 Mon Sep 17 00:00:00 2001 From: Madelyn Olson Date: Thu, 20 Jun 2024 21:47:05 -0700 Subject: [PATCH 6/7] Update topics/releases.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Madelyn Olson Co-authored-by: Viktor Söderqvist --- topics/releases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/topics/releases.md b/topics/releases.md index ee8d1fcb..3baf28de 100644 --- a/topics/releases.md +++ b/topics/releases.md @@ -70,9 +70,9 @@ Stable minor versions are created as needed in between major releases, and we ai ### Release candidate -New minor and major versions of Valkey begin by branching off the `unstable` branch as an initial release candidate branch with a name that takes the form of `*major.minor*`, example `7.2`. +New minor and major versions of Valkey begin by branching off the `unstable` branch as an initial release candidate branch with a name that takes the form of *`major.minor`*, example `7.2`. The first release candidate, or rc1, is released once it can be used for development purposes and for testing the new version. -Release candidate versions will start with a patch version of "0" and will take the form `*major.minor.patch-rcN*`, example `7.2.0-rc1` followed by `7.2.0-rc2`. +Release candidate versions will start with a patch version of "0" and will take the form *`major.minor.patch-rcN`*, example `7.2.0-rc1` followed by `7.2.0-rc2`. At this stage, most of the new features and changes in the new version are ready for review, and the version is released for the purpose of collecting public feedback. Subsequent release candidates are released every couple of weeks, primarily for fixing bugs and refining features based off of user input. From 5b3d54aba6492942635196f8f88874be448e9ef8 Mon Sep 17 00:00:00 2001 From: Madelyn Olson Date: Thu, 20 Jun 2024 21:47:21 -0700 Subject: [PATCH 7/7] Update topics/releases.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Madelyn Olson Co-authored-by: Viktor Söderqvist --- topics/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/topics/releases.md b/topics/releases.md index 3baf28de..5fc57a80 100644 --- a/topics/releases.md +++ b/topics/releases.md @@ -32,7 +32,7 @@ When discussing compatibility, we refer to the following API contracts: *Patch* versions are released with backwards compatible bug fixes and should not introduce new features. Upgrading from a previous patch version should be safe and seamless. -It should be safe to run a Valkey cluster with servers running on different patch versions. +It should be safe to run a primary-replica pair or a Valkey cluster with servers running on different patch versions. *Patch* versions may also introduce small improvements such as performance or memory optimizations that are easy to verify as safe.