How to make a release

Step-by-step instructions

• Make sure the pygmo version number is set to the correct value. The version number is at the top of the root CMakeLists.txt file, in the project() CMake directive. If the version number is not the correct one, rectify it and commit and push the changes to the pygmo repository. Although it's tempting, DO NOT [skip ci] in the commit (see the pitfalls section below). NOTE: pygmo uses a MAJOR.MINOR.PATCH versioning scheme, please make sure all 3 numbers are always defined.

• Make sure the doc/sphinx/changelog.rst file is up to date, and that the section title for the new release contains the correct version & date (e.g., "2.2 (unreleased)" is not ok, fix it with the appropriate date: "2.2 (2017-05-12)"). If you had to modify the changelog, commit and push the changes to the pygmo repository before doing anything else. Although it's tempting, DO NOT [skip ci] in the commit (see the pitfalls section below).

• Make sure that the correct version of pagmo is being used to build pygmo in the manylinux pip packages:

  https://github.com/esa/pygmo2/blob/master/tools/docker_manylinux.sh

  The correct version is the latest stable pagmo version at the time of release. If you need to bump up the pagmo version, commit and push the changes to the pygmo repository before doing anything else. Although it's tempting, DO NOT [skip ci] in the commit (see the pitfalls section below).

• Create a new release via the webpage https://github.com/esa/pygmo2/releases. It is very important that the "Tag version" field in the new release form starts with a v. That is, if you are releasing version 2.3.4, the "Tag version" field must read v2.3.4.

• The other fields in the new release form are not crucial, but please try at least to be consistent with previous releases :)

• After the new release has been created, patiently wait for the CI builds to run. If everything went ok, the new pypi pygmo packages will show up at https://pypi.org/project/pygmo/

• The conda web bots will detect the presence of a new releases of pygmo, and they will automatically open a PR to the feedstock. If the pygmo conda recipe/scripts need updating (e.g., a new dependency has been added), you'll have to go the usual route of manually cloning the feedstock, applying the necessary changes, etc.

Pitfalls

• Do not tag a release in correspondence of a commit which skips the CI services (i.e., if the commit message contains [skip ci], [skip appveyor], etc.). Doing so will prevent the CI from running, and no packages will be produced for the new pygmo version.