New versioning policy for Heptapod components

This issue mostly to gather feedback.

The problem

The current policy is to have the exact same version number for all Heptapod components: Rails application (aka Heptapod itself), Heptapod Workhorse, Heptapod Shell and py-heptapod. This is simple enough, but some components typically don't change much in stable releases. This is already the case in upstream GitLab: it doesn't happen so often for a patch release to come with any change in GitLab Shell, for instance.

The practical result is that we have to create lots of new versions for the exact same content. This is time consuming and error prone.

Context: GitLab component versions

The Rails application plays the role of the main repository, with version files for all components. For example, in GitLab 13.3 we have 8.39.0 in the GITLAB_WORKHORSE_VERSION.

Similar files are present in the Omnibus repository (responsible of packaging).

The py-heptapod version is specified in the pip requirements file, also in the Rails application repository. We'll do the same with HGitaly.

Usually, a new minor GitLab version (e.g GitLab 13.3) comes with a bump of the minor version for each component. Here's an example:

diff -r a369bef802a6 -r 1fd7e6d1f7ce GITLAB_SHELL_VERSION
--- a/GITLAB_SHELL_VERSION      Tue Jul 21 14:46:32 2020 +0000
+++ b/GITLAB_SHELL_VERSION      Fri Aug 21 12:16:22 2020 +0000
@@ -1,1 +1,1 @@
-13.3.0
+13.6.0
\ No newline at end of file
diff -r a369bef802a6 -r 1fd7e6d1f7ce GITLAB_WORKHORSE_VERSION
--- a/GITLAB_WORKHORSE_VERSION  Tue Jul 21 14:46:32 2020 +0000
+++ b/GITLAB_WORKHORSE_VERSION  Fri Aug 21 12:16:22 2020 +0000
@@ -1,1 +1,1 @@
-8.37.0
+8.39.0

(of course the diff of the component itself is not trivial)

Proposal

Starting with Heptapod 0.17.0

For Heptapod Workhorse and Shell, or any later forked component:

• the version of the Heptapod component has the same major and minor numbers (x.y) than its GitLab upstream
• each time we change anything but we don't change the minor upstream version, we increment the third number (patch). It doesn't matter if the change is a merge from an upstream patch release or actual Heptapod changes.
• we introduce new HEPTAPOD_WORKHORSE and HEPTAPOD_SHELL files both in the main repository and in Omnibus.
• we change the admin dashboard to display versions of Heptapod Workhorse and Shell based on the new files.

For py-heptapod, we could start over at 1.0.0 and adopt semver rules.

For HGitaly, we don't have any release yet, we should start at 0.1.0 in Heptapod 0.17.0 and probably call it 1.0.0 in Heptapod 1.0.0, since the latter now means we have a fully native Mercurial mode.