This section explains the full procedure for performing all steps necessary to make a new release of AiiDA. This can be divided into the following three major steps:

1. Preparing the branch
2. Merging the changes
3. Deploying the release

The first thing one needs to decide when considering to make a release is the type of release to make. AiiDA uses semantic versioning: i.e. version labels have the form v<major>.<minor>.<patch>. The type of release to choose will depend on the type of modifications included.

• Patch release: v1.3.1 to v1.3.2, only bug fixes
• Minor release: v1.3.1 to v1.4.0, bug fixes and new features that maintain backwards compatibility
• Major release: v1.3.1 to v2.0.0, bug fixes and new features that break backwards compatibility

In the following sections, we assume that the latest release was v1.3.1. Furthermore, we assume the following naming conventions for remotes:

• origin: remote pointing to aiidateam/aiida_core
• fork: remote pointing to personal fork, e.g. sphuber/aiida_core

You can check how your remotes are configured with git remote -v. To get this configuration from a fresh download, you can run the following commands

$ git clone https://github.com/aiidateam/aiida-core.git
$ cd aiida-core
$ git remote add fork https://github.com/<USERNAME>/aiida-core.git

The first step to make a new release is creating a new branch. The most general way to do this is to start from the last release and then apply over that all the changes that need to go in the new release

$ git checkout tags/v1.3.1 -b release/1.3.2

The easiest way to now incorporate the desired changes is to do so is through the pull requests involved. Each PR in github also generates the corresponding patchfile with the changes involved. For example, this would be a couple of pull request URL + patch URL for pull request number 624:

https://github.com/aiidateam/aiida-core/pull/624
https://patch-diff.githubusercontent.com/raw/aiidateam/aiida_core/pull/624.patch

You can get this patch and apply it to the current state of the branch by piping the result of curl to git am. You should do this in order (from older PRs to newer PRs) to minimize the chances of merge conflicts.

curl https://patch-diff.githubusercontent.com/raw/aiidateam/aiida_core/pull/624.patch | git am

If there is any other adaptation that needs to be done for the release, work can be done in this branch and commited directly to it until the release is ready.

The final commit in the branch has to be the release commit. Most releases will only contain this commit as its only "new" commit. The message must just mention the release version (Release `v1.3.2`) and it has to contain exclusively the following updates:

• Changelog: The CHANGELOG.md must be updated to contain the list of relevant changes in the new version.
• Authors: The AUTHORS.txt must be updated with any changes in the EPFL team (first two sections), or any new contributor to the code (third section).
• Version: The version number must be bumped up in the setup.json and the aiida/__init__.py.
• Headers: The headers of all files should be checked and updated.

The process of merging back the changes into the existing branches (master and develop) can seem to be a it farfetched or over-complicated, but sadly some care is required to make sure commits are correctly identified and not unnecessarily applied twice.

The first step is making a pull request from the release branch into master.

We will do so from a fresh install of AiiDA, in a newly created enviroment.

$ git clone https://github.com/aiidateam/aiida-core.git aiida-release
$ cd aiida-release
$ git checkout -b release_branch
$ python -m pip venv ~/envs/release
$ source ~/envs/release/bin/activate

• Update AiiDA.net download page.
• Make a "News" entry (reference download page and github).
• Publish in Facebook and Twitter using a shortened url