helm: tags and versions

tiborsimko commented 4 years ago

(1) Currently, the helm releases create tags named with leading reana-... text:

$ git tag -l
reana-0.7.0-dev20200407
reana-0.7.0-dev20200416
reana-0.7.0-dev20200417

This is not pretty. We should use v0.7.0-... as the tag name, which would give 0.7.0-... as the semver number. See semver FAQ.

Example: Kubernetes project uses leading v for tags, e.g. v1.18.0.

Example: Go uses leading go for tags, e.g. go1.14.3.

(2) Currently, the helm versions such as 0.7.0-dev20200527 are nicely semver-compliant. However, the usual practice for semver releases is to use dot-separated pre-release identifiers, going like 2.0.0-alpha.1, 2.0.0-alpha.2, etc. We don't use dot separation, and while our YYYYMMDD numbering is nice, it may not be future-proof for multiple builds in a given day.

Hence some RFCs:

Shall we go for -dev.20200527 as well, including dot?
Since we may be releasing more often than once per day, shall we go far -dev.20200527+build111023 or -dev.20200527.git.0460f28 where the later part could indicate either hh:mm:ss hour or sha1 information? (only from official repos in the latter case)
Since the connection to Python versioning (0.7.0.dev20200224) is a bit broken anyway due to dots/dashes, and since we may be having non-Python components in the future, shall we go for the classical alpha.N where N would be simply auto-incremented, loosing the date information and relying on chart overview to inform about dates?

Example: Kubernetes uses classical alpha/beta/rc denomination, e.g. v1.19.0-alpha.1.

(3) It may be good to look at future-proofing versioning, e.g. regarding Helm Hub. It seems Helm Hub supports semver2, but I have not looked at prevalent common style regarding alpha/beta/rc or dev.

tiborsimko commented 4 years ago

A related issue:

(4) Docker image versioning using git-latest-tag-plus-commits, leading to image numbers such as 0.6.0-31-g35c4fc8 for version such as 0.7.0-dev20200527. This does not seem coherent, since one is based on past tag and one is based on future tag, as it were. Perhaps we should harmonise this at the same time?

tiborsimko commented 4 years ago

Another consideration: we could abandon YYYYMMDD style and switch Python versions into using 0.7.0a1 style, which would play more nicely with 0.7.0-alpha.1 semver style for Helm releases. And we could use the same base for Docker images released on Docker Hub, followed by sha1. This might give the most coherent (pypi, docker hub, npm, helm) release numbering wherever we may be releasing.

tiborsimko commented 4 years ago

The RFC was agreed and the details were ticketised in #370 and associated r-dev tickets where things will be implemented. I'm therefore closing this RFC.

reanahub / reana

helm: tags and versions #331