Development card templates define what are the privileges of each role inside the QuNex suite development process. The list below defines these roles.

• QuNex development lead: Jure Demšar
• QuNex Container development lead: Zailyn Tamayo
• Senior developers: Zailyn Tamayo, Lining Pan
• junior developers: everyone else

• Read through the rest of the (QuNex SDK Wiki) and the repository's readme file.
• Study the existing functionality and coding patterns in use.
• New features are opened after they are discussed on a team call. Development lead or senior developers handle opening of issues and branches.

QuNex uses a derivative of the Semantic Versioning 2.0.0. The logic is as follows:

Given a version number .., we increment the:

• version when we make a major update that would significantly change the way most QuNex commands are called.
• version when we add or change functionality that could be backwards-incompatible. This contains changes to existing commands that requires users to change the input parameters or that could result in different outputs. This also contains changes to external libraries (e.g., FSL or HCP Pipelines), that could potentially result in slightly different results.
• PATCH version when we make backwards-compatible bug fixes that do not change the outputs, results or command calls in any way.
• SUFFIX version is a letter appended to the version when only container changes are made. This happens when, for example HCP fixed a minor bug on their end and we need to pull it into the container. In this case the version number stays the same, the difference is denoted as a letter appended to the version number, for example 0.95.3 becomes 0.92.3a.

Whenever you make a change to the code it should be reflected in the versioning files (CHANGELOG.md, README.md and VERSION.md). When finishing a feature it is most convenient to first merge it into the develop branch and then update the versioning, this way you will avoid any versioning conflicts. The QuNex suite library submodule (qx_library) has its own versioning and versioning files. When updating the versioning of the library submodule the change also has to be reflected in the main QuNex README.md file.

We use git to manage the QuNex codebase, below are the some basic Git guidelines. If you are unfamiliar with Git you should catch up by reading or watching some Git tutorials (e.g. https://git-scm.com/docs/gittutorial). Details about how we facilitate Git can be found on the DevOps Wiki page.

Before making any changes to the code, always check that you are working with the latest version of the code. To get the latest version, in the terminal in the repository top folder, type:

git pull

If you don't update the code to the latest version, you won't be able to push your changes to the repository before pulling and merging them with the changes on the repository. In a more severe case you might introduce conflicting changes, which you will have to resolve manually.

When writing the code, make sure that:

• the code is written in legible and clear manner with informative variable names,
• it is documented inline, so that it is possible to reconstruct what it does,
• it outputs reports so that the user can follow the progress in the execution of the code,
• it includes reasonable checks and warns user of errors in data and parameters,
• all the changes are reflected in the command help / documentation.

Check the code thoroughly before committing it. Once you are reasonably sure that the code works and it does not introduce bugs, commit the code using:

git add <changed files>
git commit -m "<commit message>"

or

git commit -a -m "<commit message>"

when you want to commit all the changes in the working directory.

Be sure to write succinct and informative commit messages. Make atomic commits, meaning, if you made unrelated changes to the code, commit each of the changes separately. See the Writing Commit Messages Wiki page

When you are sure that your code is working well and is ready to be included in the main repository, push the code to the repository using:

git push

At this point you might be warned that other commits are already in the repository. In this case you might need to pull the latest state of the package from the repository, merge the changes and possibly resolve any conflicts before the merge can be committed and pushed to the server. These steps are outside of the scope of this documentation. Please consult git tutorials and documentation.