Madelyn Olson

Marking to closed unless anyone else comes in an advocates for it.

Sounds good to me. We need to define our EoL strategy first, then we can post a file there.

Okay, we finally defined our EoL policy and defined it [here](https://github.com/valkey-io/valkey-doc/blob/main/topics/releases.md)! If someone wants to help and create a file in EoL repo, they can use that as a reference

Historically we have predominantly used atomics for counters in other threads, which are fine with `memory_order_relaxed` and see better performance.

@pizhenwei The numbers do look great. I haven't gotten a chance to look at it yet, hopefully some time this week.

> ... and if we do want to support DENSE, I think the slot ranges should be represented as a flat multi-range list [start1, end1, start2, end2, ...] rather than...

@barshaul Also, the cluster slots output is sorted now, so it should be deterministic.

> Nice, thanks. Was sorting the replicas added in version 8.0? Yes, see https://github.com/valkey-io/valkey/pull/265. Replicas are ordered in `CLUSTER SLOTS`. > However, it's still not ideal to use cluster slots...

I think the main downsides are we have to do more work to figure out which shard the node maps to (it's Log(N) where N is the number of ranges)...

> Few ranges per shard is also acceptable. If it gets too fragmented, we can defrag... valkey-cli --cluster defrag. Or some incremental slot-defrag while scaling, so the fragmentation is bounded...