Skip to content

Latest commit

 

History

History
14 lines (10 loc) · 1.86 KB

DEV_README.md

File metadata and controls

14 lines (10 loc) · 1.86 KB

This document is meant for developers of CAJAL rather than end users.

Releasing a new version of CAJAL

You must follow a certain workflow in releasing a new version of CAJAL so that the Github Actions continuous integration workflow does certain mundane tasks automatically (uploading wheels as assets on the Github release page, and pushing the wheels to PyPI)

To release a new version of CAJAL,

  1. Change the version number locally in the README.md ("New in this release"), and in pyproject.toml.
  2. Make the final git commit locally which is intended to be the publicly facing new release (or an alpha or beta version)
  3. Run git tag -a v1.0.1-alpha.5 -m "Prerelease 5 of version 1.0.1-alpha of CAJAL", replacing v1.0.1-alpha.5 with the desired tag number (and following semantic versioning conventions). The tag name must start with the letter v to trigger the CI.
  4. Run git push origin v1.0.1-alpha.5, where origin is the name of the CAJAL github repository. You must include the name of the tag as the last part in the push command, or it will not push the tag to Github, and the presence of the tag is what triggers the conditional branch in the CI script.
  5. Wait and check to see that the wheels build correctly and are uploaded to PyPI.

N. b. - I estimate that around 80% of the compilation time for the wheels is spent compiling C++ code dealing with 64 bit floating point to run on 32 bit Linux platforms (i686), I assume this requires some kind of convoluted compilation technique. When making a new release, I suggest making an alpha or beta release of the new version first, in order to test and debug the continuous integration; and in the beta release, uncomment the line in the "Build wheels job" that filters out the i686 build targets (here)[

CAJAL/.github/workflows/python-package.yml

Line 38 in b152170

*i686
]