Skip to content

Preparing a release

Jump to bottom
Janez Demšar edited this page Jun 10, 2024 · 66 revisions

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 (name of the branch should be releases/pre-) 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 the 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

Build wheels and publish to PyPI

Make a GitHub Release from the tag with the name Release <version>. It triggers the wheel-building GitHub actions, which builds wheels (takes cca 20 min) and publishes them to PyPI.

Update version at conda-forge

Create a pull request on orange3-feedstock, which bumps the orange version and hash in the recipes/meta.yml file. You can create a pull request:

  • Open an issue with @conda-forge-admin, update version in the title section
  • Wait an hour or two for a bot to open PR automatically.
  • Manually initiate a PR from the repository fork

The first two options are preferred. Merging this PR will trigger a build of updated packages on conda-forge.

Update Wikipedia Page

Update the version Wikipedia, supposedly here. (Remove "supposedly" if this works.)

Build installers

The last and 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 to, e.g. 3.8.0 in all workflows in the .github/workflows directory and in the .cirrus.yml file. 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 the BUILD_LOCAL flag in workflows.

Built installers are kept as build artefacts:

  • GitHub Actions: click green check beside commit > Details > Summary. You will find Artefacts at the bottom of the page.
  • Cirrus: click green check beside commit > Details > View more details on Cirrus CI. Search for the Artefacts section.

You need to gather five installers:

  • Orange3-3.36.2-Python39-win_amd64.exe
  • Orange3-3.36.2-x86_64.exe
  • Orange.zip (portable installer)
  • Orange3-3.36.2-Python3.9.12-arm64.dmg
  • Orange3-3.36.2-Python3.9.12.dmg

Sign MacOS installers

To sign the MacOS installer, run scripts/macos/sign-dmg.sh <path to installer> (the script is in the orange3-installers repository) on a Mac with the appropriate developer certificate installed (At the time of writing this, @ales-erjavec, @jakakokosar, @primozgodec, and @markotoplak have the UL FRI certificate). Then, notarize it according to the workflow here.

Sign Windows installers

To sign the Windows installer, run (in PowerShell) something like

& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe" sign /fd SHA256 /n "Univerza" /t http://timestamp.digicert.com Orange3-3.8.0-*

on a computer with YubiKey containing the certificate (When writing this, @markotoplak has it; he also knows the PIN).

Publish installers

When installers are built and signed, they must be uploaded to biolab@ssh.download.biolab.si and put into dir /srv/download/. Then, log into ssh.download.biolab.si and edit /srv/version/orange.txt and set the current version. Verify that https://orange.biolab.si/version/ now returns the new version.

To update installers on the website, make a pull request to https://github.com/biolab/orange-web2, where you change the Orange version in config.json.

Clone this wiki locally