Update/Unify release process and changelog management

[claustres]

The current release process is different for modules and applications, we should analyze if it's possible to make them more similar in order to avoid confusion. Moreover, there are two different changelog generators currently used.

github-changelog-generator used in Weacast, Krawler, KDK and derived applications creates a log file based on tags, issues and merged pull requests from :octocat: GitHub (so it cannot work with eg GitLab). It requires to install (e.g. for Windows) Ruby and its DevKit. Last but not least, it suffers from the following issue so you might have to edit the generated changelog when pushing on different branches or systematically merge changes to master before generating the changelog so that all issues are closed in Github.

generate-changelog used in Kaabah, Kargo and Krawler jobs creates a log file based on git commits (so it can work with eg GitLab). It does not require any third-party dependency. However it suffers from an issue so that if the commit message includes a URL it will break. Morevover, we did not test it with branches. Last but not least, it does not allow to integrate into the changelog issues that have been closed without any related commit (eg a bug appearing in an app and coming from the KDK dependency).

The following automated process applies when releasing a patch, minor or major version of a module using the first changelog (eg KDK):

1. increase the package version number in the package.json file
2. publish the module on the NPM registry
3. create a tag accordingly in the git repository and push it
4. generates the changelog in the git repository and push it

A different process applies for the apps as:

• it is not published on the NPM registry but in the Docker Hub
• it is far less automated to ensure more flexibility so that the build artifacts of the different flavors can be managed independently.

Imagine we are currently working on the next version of the app (1.2.0 in package.json =>1.2.0-dev image in Docker Hub) on the master branch:

1. start a new release by creating a test branch from the master branch (test-1.2 =>1.2.0-test image in Docker Hub)
2. increase the version number (major or minor) of the master branch so that the previously generated artifacts will not be erased by new commits (1.3.0 =>1.3.0-dev image in Docker Hub)
3. when you are ready to release create a tag on the test branch (prod-v1.2.0 =>1.2.0-prod image in Docker Hub) in the git repository and push it
4. generates the changelog in the git repository and push it
5. increase the version patch number of your test branch (1.2.1 in package.json =>1.2.1-test image in Docker Hub) so that the previously generated artifacts will not be erased by new commits entering pre-production

The following automated process applies when releasing a patch, minor or major version of a module using the second changelog (eg Kargo):

1. generates the changelog in the git repository and push it
2. increase the package version number in the package.json file
3. publish the module on the NPM registry
4. create a tag accordingly in the git repository and push it

The process used for the modules does not allow to manage multiple branches. Indeed, each commit on the master branch erases the latest tag on the Docker Hub while any tag generates a release (eg 1.2.0 tag).

We have tried to use a similar process for customer-specific applications based on Kano, eg GIFT. However, it is not really finished and causes some problems. First by erasing the previous image while committing on the next release, ie the version number remains eg 1.2.0 until the 1.3.0 release has been published so that the 1.2.0-dev image in Docker Hub actually contains the next 1.3.0 release code. Second because we assume that similar versions exist in dev/test flavor while patch versions only exist in test flavor.

[claustres]

A solution to be able to use a similar process between modules and apps is to avoid versioning dev/test Docker app images and only number prod images. Indeed, there is no need, in this case, to increment the version number on the master/test branch after a release as the previously generated artifacts (dev/test) will be erased anyway.

The problem with this approach is that we cannot have multiple versions of Kano running in different production environments simultaneously. Indeed, as a new Kano release will erase the image of the previous one, any custom build relying on the previous image will not be able to run anymore. This process could be acceptable on customer-specific applications based on Kano but not on Kano itself. We should at least manage a dev/test branch and accept that when a version enters the test flavor no patch is possible on the running production version as the code in the test branch has been upgraded.

[claustres]

About changelog we now use GitHub/GitLab issues to track changes in order to simplify the release process.

[cnouguier]

Since we we use Github/Gilabl track changes, we can close this issue