Road to Release: 1.0.0

[stockholmux]

This is a living issue to track the scope of the 1.0.0 release of the Valkey Kubernetes operator. The goal of this issue is to corral ideas and end up with a clearer view on how and when we get to a production ready operator for Valkey.

Background
The Valkey RFC process is known to be... imperfect... at the time of writing. However valkey-io/valkey-rfc#28 from Oct 2025 has several comments and feels like our north star and GA goalpost.

There is also some work in the project discussions, including a 0.1.0 topic, but I'd like to move from discussions, which are more open ended, to an issue where we more easily decide, close, and assign to boards.

Questions

1. Do we still agree that the RFC reflects our current goal post?
2. Is there any merged work that is not reflected in the RFC?
3. Is there any non-merged work that needs to be reflected in the RFC?
4. Is there any non-core functional work that is needed for 1.0.0 (e.g. valkey-io/valkey-doc PRs, release blog posts, etc.)
5. How many initial development versions do we need to have before 1.0.0 and what is our pre-GA pre-release strategy (e.g. RC releases)
6. Is there any target dates which we need to work backwards from?

Output
Based on the output from the conversation this issue I'll capture the responses and create issues for all open tasks and assign them to boards for releases (each initial development, GA, and post GA).

Known relevant folks
@jdheyburn @dmolik @bjosv @ysqyang @sandeepkunusoth @hieu2102 @SuperQ (please excuse any omissions and tag people in as needed)

[jdheyburn]

I think we would need to rework the RFC to reflect discoveries and requirements that have surfaced since we started work on this.

In my eyes, I am wary of calling the operator production-ready (my interpretation of 1.0.0) until we have faith that no data is going to be lost, and that we do not introduce regularly breaking changes in the CRD. The latter of which is why I have been somewhat opinionated in the CRD design, so that we save ourselves a breaking refactors later on.

• (rfc): Design Proposal for additional CRDs #63
• RFC for ValkeyNode CRD proposal #83

Having said that, we can probably agree to something like this for development versions:

• 0.1.0
  • MVP Valkey Cluster, no data durability guarantees, no resharding (slot migration)
  • If that's the case then this is ready now
• 0.2.0
  • Valkey Cluster with data durability, resharding (this is what @ysqyang is working on)
• 0.3.0
  • ValkeyNode internal CRD, support for StatefulSets

We would need to align on what 1.0 looks like; is it beyond Valkey Cluster? If yes, then we would need to build out the extra components to support non-Cluster workloads (which my org uses extensively):

• Standalone Valkey
• Valkey with replication (Operator manages replication)
• Valkey with replication (Sentinel manages replication)
• Valkey Pool (Operator manages non-Cluster shards of Valkey)

[stockholmux]

Thanks for the feedback @jdheyburn.

IMHO, we should settle on the RFCs prior to cutting a 0.1.0 tag. I'd like to at least know where we're going before putting anything out there. I also agree that the CRD needs to be stabilized at 1.0.0; if we're trying to go for semantic versioning (which is the project standard) then I think we should try to avoid churning majors all the time.

I have use cases for non-clustered Valkey as well, although we should have an honest discussion about scope for 1.0.0 and if we could manage to do a minor release with these non-clustered workloads. Ideal world: 1.0.0, potentially with some non-clustered workloads, comes out and a relatively fast follow with minors releases that support more varied types of workloads.

[bjosv]

I currently have some notes/answers for the questions:

1. The RFC describes a CRD called Valkey and that we may split that multiple CRDs, current thinking in my view is to have them splitted from start.
2. All merged seems covered
3. User/ACLs is not mentioned in the RFC, same with external access using loadbalancer/proxy