Versioning strategy

[chayim]

Our current versioning strategy is inconsistent. This issue exists to define the versioning method we'll use - naming-wise, and then extend it to multiple items. At a minimum the build systems will be changed to:

1. Publish docker tags using this versioning strategy
2. Publish binary images to s3 using this strategy

To support this the following version tag definition is proposed:

$PRODUCT-$VERSION-$OSNICK-$PLATFORM(?-$EXTENSION)

Examples of this include:

• redisgears-master-bionic-arm64
• redistimeseries-1.2-bionic-x64
• redistimeseries-1.2-edge-buster-x64-somespecialtag

This naming convention will be used in both situations - meaning that dockers will be built with the tags above, in addition to artifacts (.tar.gz, .ramp, etc) being made available using this naming convention, in s3. S3 paths themselves are to change, as discussed in #23

Versioning outputs

master: The master (HEAD) builds will product artifacts where the version is edge.

versioned branches: Versioned branches (1.2, 1.4) product artifacts where the version is version-edge (i.e 1.2-edge).

release tags: Release tags (v1.2.3, v1.4.0) will product artifacts where the version is version (i.e. 1.2.3, 1.4.0).

latest: The latest tag will manually pushed back to dockerhub (or tooled) such that it points to the latest release as per product management.

The open question exists, do we need a tag such as 1.2-latest.