QuNex suite development is organized into release cycles. Each release cycle depicts a major update to the QuNex suite and a public release of this new version. Currently active release cycle is described by the release issue on GitHub. This issue contains the main functionalities that will be integrated in the next publicly released version.

There are three types of development tasks: major, minor and patch. When opening an issue

Major development tasks are those that either introduce a new functionality into the QuNex suite or those that significantly modify current functionalities. The most common introduction of a new functionality is the implementation of a new user facing command. A significant modification of an existing functionality is something that requires users to change the way they use a certain command (e.g. the new functionality is not backwards compatible with the previous one). Thus, a good rule of thumb for deciding whether a development task is major or minor is the requirement of additional acceptance tests. If the development task requires new or modified acceptance tasks then it is most likely a major task.

Minor development tasks most commonly come in the form of fixes, bug squashes, optimizations ... These tasks usually do not span over several of QuNex submodules and do not require any alterations to acceptance tests or to the way that users use QuNex. However, the amount of work required to execute is not negligible and executing this work on a separate feature branch makes sense.

Patches are the shortest of development tasks. These are quick fixes or bug squashes that require you to fix only a line of code or two and can be executed extremely quickly (less than an hour). Opening feature branches for this work makes no sense and development is executed directly on the develop branch. Since you will be working directly on the develop branch, which has to be in a working state, coding patches directly is allowed only to senior developers and development leads. The develop branch is the hub which is commonly used for testing and for opening new features so it needs to be in a working state!

While developing the QuNex Suite we are facing two additional challenges. First, QuNex also includes a library submodule (qx_library). To setup your own development environment you have to provide the following folder structure in your $TOOLS folder:

• qunex - a folder where the master branch of the qunex repository and all its submodules is checked out.
• qunexdev - a folder where the develop branch of the qunex repository and all its submodules is checked out.
• qunexfeatures - a folder where the feature branches will reside.
• qunexsdk - a folder where the master branch of the qunexsdk repository and all its submodules is checked out.

To use and test the right branch/clone, the OS environment has to be properly setup. To set up a standard development .bash_profile, add the following to your personal .bash_profile:

export TOOLS=<path_to_the_root_of_qunex_repositories>
source $TOOLS/qunexsdk/qunexdevops/environment/qunex_sdk.profile

Note that qunex_sdk.profile should be sourced before the core QuNex environment is sourced.

Now you can use the following commands to edit and review the environment:

• qx_reportenv - to show the current QuNex clone and environment,
• qx_showenvs - to show the available environments,
• qx_setenv - to set the desired environment.

Branches for new functionalities or fixes are opened by the development lead or senior developers. Branch names need to start with a number and a dash, followed by the branch name. This way branches are automatically linked with issues.

Once the development on your branch is finished, trigger a merge request (MR) via the GitHub portal. If this is a hotfix MR should target the master branch while in other cases it should merge into the develop branch. Assign one of the senior developers as a reviewer of your MR and they will take it from there.

Legacy branches are not part of the GitFlow branching model but are required for our specific use case. From time to time a scenario arises where we have to fix a bug in a legacy version of the codebase (a version of the codebase that is deprecated and no longer maintained). One of such scenarios is that we want to remove a bug in code and re-process some data by using the exact same version of QuNex that was used for processing the first time around. For this purpose we use legacy branches. Legacy branches are named as legacy/<version> only development lead and senior developers are allowed to open these branches.

Because legacy branches work with unsupported code versions is is impossible to develop an automated process for checking out all appropriate branches and preparing the development environment. This means that you will have to checkout and label appropriate commits manually (in all submodules and probably also in the qunexcontainer repository). This can be done in git as:

git checkout 99f0a18e63d7d06cf5a05c46476c72c9edc3f1e4 -b legacy/0.48.20a

where 99f0a18e63d7d06cf5a05c46476c72c9edc3f1e4 is the commit hash and legacy/0.48.20a the legacy branch name. It is important to use the -b option here. If not, your checkout will result in a dangling commit which can quickly get messy.