Preparing a release

This is a collection of notes made during the release process of 3.3.2 and slightly updated when releasing 3.7.1. Most of the tasks should be automated. The rest can be used as a guide for the following releases.

First, check open pull requests and decide, which of them should make it to the current release. Assign them to the current milestone (3.11). Now check all pull requests/issues in current milestone. If any of them are not ready yet, move them to the next milestone (3.12). For those that remain, nag authors to complete/rebase/test them until they do.

Final check. Try building installers for orange3/master by making a new branch at https://github.com/ales-erjavec/orange3-installers. We had problems with forgotten dependencies before. Make sure that the tests for the new branch pass.

After all changes have been done and accepted, pull the latest stable and master.

git checkout stable
git pull
git checkout master
git pull

If you are doing a patch release, you first have to check out the latest released version. If you are doing a minor released, skip this step.

git checkout 3.7.0

Create a release branch

git checkout -b release-3.7.1

For patch releases, all required changes that should make it into a release should be manually cherry-picked. For minor releases this step should be skipped.

git cherry-pick -m 1 <hash>

Set ISRELEASED flag in setup.py to True. If you are doing a patch release (updating the third number), update the version as well.

Collect the lists of enhancements and fixes

scripts/create_changelog.sh

Manually incorporate these lists into CHANGELOG.md. Don't forget to update the links at the end of the file.

Now commit these changes:

git add CHANGELOG.md setup.py
git commit -m "Release 3.4.4"

Tag commit as new version:

git tag 3.4.4

If you are doing a patch release, merge the changes onto master, discarding the changes to the setup.py in the process.

git checkout master
git merge --no-ff --no-commit release-3.4.4
git checkout HEAD -- setup.py
git commit

If you are doing a minor release, update setup.py, bump version (3.6.0) and set ISRELEASED to False. Commit the change and merge all changes into master.

git add setup.py
git commit -m "Bump version to 3.6.0-dev"
git checkout master
git merge release-3.4.4

Push changes to master.

git push upstream master --tags

After a successful push, update stable branch to the newly-released version.

git checkout stable
git merge 3.4.4

Branch stable is also pushed manually to github.

git push upstream stable

So far so good.

Trigger the build of OSX and windows wheels by updating the version in the master branch of the https://github.com/ales-erjavec/orange3-wheels repository. In about 10 minutes, the built files will appear on https://anaconda.org/ales-erjavec/orange3/files

Download the OSX and windows wheels (6 files) to dist dir inside your repository. Add a source distribution by running the following in a clean working directory (also make sure setuptools-git is not installed)

python setup.py sdist

And upload the file to pypi using twine

twine upload dist/Orange3-3.4.4*

Create a pull request on orange3-feedstock which bumps orange version and hash in recipes/meta.yml file. You can download the archive and get its hash with

wget https://github.com/biolab/orange3/archive/3.8.0.tar.gz
openssl sha256 3.8.0.tar.gz

Merging this PR will trigger a build of updated packages on conda-forge.

Every once in a while, you might consider publishing the release on GitHub.

The last and probably the most complicated step is building the installers for windows/macos. Recipes for building both are available at https://github.com/ales-erjavec/orange3-installers where a separate branch is created for each release (i.e. releases/3.8.0). On the new branch, change BUILD_COMMIT from HEAD/FETCH_HEAD in .travis.yml/appveyor.yml to e.g. 3.8.0, commit the changes and push. If packages are already available at conda-forge, and you do not want to build the package locally remove 1 beside BUILD_LOCAL flag in .travis.yml/appveyor.yml.

Built installers are kept as build artefacts on appveyor/travis. For windows installers, click the little green checkbox in commits page on GitHub to get to the appveyor page for the build, then select a job (e.g. "Environment: ...") and select the right-most-tab (Artifacts). Installer for MacOS can be found at the bottom ob job log (Travis build). You need to expand the log that says something like this $ echo $(curl -fS --upload-file orange3/dist/Orange3-*.dmg https://transfer.sh/. There is a download link for unsigned installers.

To sign the installer, run scripts/macos/sign-dmg.sh <path to installer> on a mac with appropriate developer certificate installed (At the time of writing this, @ales-erjavec, @jakakokosar, @primozgodec, and @astaric have the UL FRI certificate). To sign windows installer, run (in PowerShell) something like

& "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe" sign /fd SHA256 /t http://timestamp.verisign.com/scripts/timstamp.dll Orange3-3.8.0-*

on a computer with the appropriate certificate installed (I use x-lbi VM for this). (At the time of writing this, @astaric, @jakakokosar, and @lanzagar have the UL FRI certificate, it is also installed on the x-lbi VM).

When installers are built and signed, they need to be uploaded to [email protected] and put into dir /srv/download/. When everything is there, modify filenames.set (in the same folder) to point to the new installers. Afterwards also modify versions.json so that the webpage will show the latest version.

Open an issue at AnacondaRecipes repository https://github.com/AnacondaRecipes/orange3-feedstock/pulls where you tell maintainers that new version of Orange is available and is already at conda-forge (you do not need to do any changes since they take the recipe from conda-forge - just let them know). They will then update a version of orange at Anaconda (default) channel. It will also make a new version available at Anaconda navigator.