Tracking Operator updates and Helm releases

[devdattakulkarni]

This repository contains all the operators code.

• When any operator code is complete we should create a new release. Trouble with following semantic versioning for this repo is that each operator is independent of others. If we update Moodle Operator's public API then we bump the major number. But later if we update Postgres Operator's internal implementation then without changing its public API then we should be updating only the minor number. But when Moodle Operator was changed we had already bumped the major number. In reality that major version bump will break the expectation for Postgres operator users even before we trying to make a change to accommodate minor version change.

So looks like Semantic versioning does not play nicely with Mono repos.

So what should we do?

I guess simplest approach is we follow a monotonically increasing number scheme when tagging a release in this repo. Then in each Operator's helm chart we include this release tag number so that we know exactly which version of the code has been used when creating the Helm chart. What about the Moodle container? What versioning number scheme should we use for that? It makes sense to use semantic versioning for tagging Moodle container images. However, if we do that how/where can we maintain the association between the monotonically increasing release numbers of the code and the semantic versioning numbers of the container images?

One option is we combine the two schemes. Basically tag the container image as:
releasenumber-semantic-version-number

Semantic version numbers are incremented as per its own rules based on whether external API has been modified or not.