Search module versioning strategy

[allenss-amazon]

The proposed versioning scheme for Search is that the Search module will have its own version numbering scheme that is not directly connected to the Valkey versioning scheme. In other words, search module releases need not be synchronized to Valkey core releases.

The strategy for selecting specific search module releases for inclusion (bundling) with other Valkey modules and the core is explicitly out of scope for this discussion item -- this issue should be taken up by the Valkey-core team.

The search numbering scheme will follow standard semantic numbering with a major.minor.patch version number.

Any of these items will require a major release number increment:

1. A change to existing behavior that would reasonably expect to break an existing application.
2. Any RDB format change that is NOT backward compatible.
3. A substantive increase in resource consumption for existing functionality (i.e., more memory or CPU used)

Any of these items will require a minor release increment:

1. New functionality is added that has no visible impact on operations if not used.
2. A substantive decrease in resource consumption for existing functionality, i.e., less memory or less CPU is used.

With the above rules, users should have high confidence that updating an existing search module deployment to a new version with the same major number and a higher minor and/or patch version number will not affect that deployment.

Compatibility of the search module with the different releases of Valkey core will get documented. It's expected that this will be open ended, i.e., a particular version of the search module will have an explicitly stated minimum Valkey-core version requirement but it should run properly on Valkey-core releases after that.