Valkey Module Versioning Strategy

[joehu21]

While we see more and more Valkey modules are being developed (bloom, json, search, etc.), it's time to discuss the general strategy or guideline for module versioning.

Should valkey module follow semantic versioning scheme? Should we decouple module version from valkey core version? Should each module version define a minimal valkey core version that it is compatible with?

Semantic Version

A module's semantic version has three parts - MAJOR.MINOR.PATCH. The mapping from the semantic version to a single version number is:

version number = MAJOR * 10000 + MINOR * 100 + PATCH

• MAJOR: Bump the major version when there’s a module API change or RDB forward compatibility is broken.
• MINOR: Bump the version when a new feature is introduced. Q: Should we bump the minor version when RDB forward compatibility is broken?
• PATCH: Incremental bug fixes. No new feature should be introduced.

For example, the following JSON module version is 1.1.0.

127.0.0.1:6379> module list
1) 1) "name"
   2) "json"
   3) "ver"
   4) (integer) 10100

Minimal Compatible Valkey Core Version

Each module version should define a minimal compatible valkey core version, which allows us to decouple module version from the core version.

Decouple Module Version from Core Version

When a new module version is released, its release branch can be named according to its own semantic version, which is independent from the valkey core version. The only thing to link the two together is the minimal compatible valkey core version.