Git branches

Branches used in CI

There are four main branches used in the automated build process of the application:

• main - reflects the sources of the currently published application in the stable (latest) channel

• beta - reflects the sources of the currently published application in the beta channel

• alpha - reflects the sources of the currently published application in the alpha (dev) channel

• develop - the main working branch where a feature branches are merged into

The main, beta, and alpha branches have CI scripts that perform a build once a branch is merged with them. They are testing the application (again) and run the electron-builder that is configured to build the application for Windows, macOS, and Linux. For the Windows and macOS builds the builder signs the application with configured certificates *these certificates are provided by MuleSoft). Additionally, the macOS build is notarized with Apple notarization service.

Development workflow

When starting working on a new feature or a fix a new branch is created from the develop branch with a meaningful name related to the task, staring with fix/[fix name] or feature/[feature name]. Once the work is done the branch is merged through a PR with the develop branch. This does not trigger any action.

Critical big fixes

When a critical bug fix is to be released imminently after the application was patched the the flow starts with creating the fix branch from the main branch. This is required as this branch gets updated the least and has the stable version code base while other branches may include features that are not yet ready to be published.

After the work on the fix is ready the branch gets merged to all four main branches through a PR. With each merge the correct application version has to be set manually (ARC has not automatic version bumping logic). After the merge is completed for each branch the application is being released for the corresponding channel.

Releasing the application

When a new version of the application is ready it goes through three stages of the release process.

Alpha (dev) channel

This channel has always a one major version higher than the stable channel. This channel is to test new features. Each time a feature is merged with the develop branch and this feature is ready to be shipped in the alpha channel a PR is made to the alpha branch. Once the branch is merged an automated build is being triggered.

Beta channel

The beta channel has the next major version release candidate after all features for the release are finalized. A PR from the alpha branch is being created with the updated version, which is one major version higher than the current stable application version. Once the PR is merged the build script is triggered.

Stable channel

After release candidate from the beta channel is "enough tested" a stable release can be performed. Similarly to other channels, a PR from the beta branch is being created. Once merged it triggers the tests and the build process.

Final release

The release process in mostly automated as described above. However the automated publishing script does not actually publish the GitHub release. This is done manually by team members having a right to publish a GitHub release. This involves building a changelog as a release info and finally publishing the prepared binaries.