[QUESTION] How will versioning work?

[stockholmux]

Is PlaceholderKV looking to continue current versioning and whatever is next after 7.2.4 for the next release? Or start over from 1.0.0?

Also, what is the versioning scheme? The previous project was nominally SemVer but there was definitely some non-adherence to the spec. If SemVer is the methodology, I'd love to see an explicit definition of the public API.

[PingXie]

I think the primary constraint here is application compatibility. We would like to make sure the very first release is as compatible as possible with 7.2.4 so that existing users can (live) migrate to it seamlessly. Given that there could already be unintended dependency on the existing versioning scheme, the safest thing to do is to continue with that, at least for the first release. Afterwards, we are not obligated to the existing versioning scheme but seamless upgrade will remain the top priority.

You can find the core team's discussion at https://github.com/orgs/placeholderkv/discussions/31.

[zuiderkwast]

Yeah, we'll start on 7.x compatible with Redis and then we'll release 8.x or greater and we can diverge from Redis.

#43

[stockholmux]

@zuiderkwast

I get the 7.x line strategy. But otherwise i'm a bit confused. You bring up 8.x but this conversation says starting with 10. Did that get decided somewhere else? It doesn't seem to be mentioned on #43

Additionally I'm still unclear what versioning methodology Valkey will follow.

[madolson]

There will be an initial version which will be 7.2, this will purely be a compatibility release.

At some point we will release a new major version, which will be the first major version of Valkey. Because we intend to launch 7.2 as the first version, we think it makes sense to use either 8 (or some higher number like 10 (to differentiate it from Redis community) or 24 (for the year)).

[zuiderkwast]

@stockholmux Yeah, there is no definite decision yet about the future version numbers. We need to focus on the first release first.