Check out all of the FEniCSx components on the release branch.
Check that all CIs on main are running green.
Check that the main documentation looks reasonable at
https://docs.fenicsproject.org.
As of 18/07/2025 the Windows CI is broken and consequently only @minrk can test the Windows build via the Condaforge CI.
The release proceeds in a bottom up manner (UFL, Basix, FFCx, DOLFINx). pypa packages cannot be deleted and should be made a number of days after the creation of git tags so that errors can be fixed. GitHub releases can have their version notes updated, and can be deleted and remade on new tags (not recommended).
The release process consists of the following steps:
- Update version numbers and dependencies on the
releasebranches. - Run integration tests, ensuring that the
releasebranches work together. - Make git tags on the tip of
release. - Organise production of release artifacts.
- Update version numbers on
main. - Make GitHub releases (not permanent)
- pypa releases (permanent!).
At the current phase of development (<1.0) FEniCSx components are typically
bumped an entire minor version i.e. 0.+1.0.
UFL still runs on the year-based release scheme.
-
Merge
origin/mainintoreleaseresolving all conflicts in favour ofmain.git pull git checkout release git merge --no-commit origin/main git checkout --theirs . # files deleted on `main` must be manually git `rm`ed git diff origin/main -
Update the version number in
pyproject.toml, e.g.2022.2.0. -
Commit and push.
-
Check
git diff origin/mainfor obvious errors.
-
Merge
origin/mainintoreleaseresolving all conflicts in favour ofmain.git pull git checkout release git merge --no-commit origin/main git checkout --theirs . # files deleted on `main` must be manually git `rm`ed git diff origin/main -
Update version numbers in
pyproject.toml,python/pyproject.toml,CMakeLists.txtandcpp/CMakeLists.txt. -
Update the Basix nanobind type stubs following
basix/python/README/md. -
In
pyproject.tomlupdate thefenics-ufloptional dependency version. Onmainthis is often pointing at the git repo, it needs to be changed to a version bound e.g.>=2024.1.0,<2024.2.0. -
Commit and push.
-
Check
git diff origin/mainfor obvious errors.
-
Merge
mainintoreleaseresolving all conflicts in favour ofmain.git pull git checkout release git merge --no-commit origin/main git checkout --theirs . # files deleted on `main` must be manually git `rm`ed git diff origin/main -
Update the version number in
pyproject.toml, e.g.0.5.0. -
Update the dependency versions for
fenics-basixandfenics-uflinpyproject.toml. -
If necessary, update the version number in
cmake/CMakeLists.txt, e.g.0.5.0. -
Update the version number macros in
ffcx/codegeneration/ufcx.h. Typically this should match the Python version number. Remember to change theUFCX_VERSION_IS_RELEASEtotrue. -
Commit and push.
-
Check
git diff origin/mainfor obvious errors.
-
Merge
mainintoreleaseresolving all conflicts in favour ofmain.git pull git checkout release git merge --no-commit origin/main git checkout --theirs . # files deleted on `main` must be manually git `rm`ed git diff origin/main -
In
cpp/CMakeLists.txtchange the version number e.g.0.5.0. -
In
cpp/CMakeLists.txtchange the version number in thefind_package(ufcx),find_package(UFCx)andfind_package(Basix)calls. -
In
python/pyproject.tomlupdate the version to e.g.0.5.0and update the dependency versions forfenics-basix,fenics-ffcxandfenics-ufl. -
In
CITATION.mdupdate the version numberversion: 0.5.0and the release datedate-released: 2022-03-14. -
In
.github/ISSUE_TEMPLATE/bug_report.ymladd a new option to the version numbers. -
Commit and push.
-
Check
git diff origin/mainfor obvious errors.
Although lengthy, integration testing is highly effective at discovering issues and mistakes before they reach tagged versions.
At each of the following links run the GitHub Action Workflow manually using
the release branch in all fields, including the . Only proceed to tagging
once all tests pass.
Basix with FFCx: https://github.com/FEniCS/basix/actions/workflows/ffcx-tests.yml
Basix with DOLFINx: https://github.com/FEniCS/basix/actions/workflows/dolfinx-tests.yml
UFL with FEniCSx: https://github.com/FEniCS/ufl/actions/workflows/fenicsx-tests.yml
FFCx with DOLFINx: https://github.com/FEniCS/ffcx/actions/workflows/dolfinx-tests.yml
Full stack: https://github.com/FEniCS/dolfinx/actions/workflows/ccpp.yml
Make appropriate version tags in each repository. UFL does not use the v prefix.
git tag v0.5.0
git push --tags origin
Documentation should be pushed automatically to FEniCS/docs on the creation
of tags. You will need to manually update the README.md.
First create tagged development and test environment images, e.g. v0.5.0:
https://github.com/FEniCS/dolfinx/actions/workflows/docker-dev-test-env.yml
Then create tagged end-user images setting the base image as the tagged development image:
https://github.com/FEniCS/dolfinx/actions/workflows/docker-end-user.yml
The tag prefix should be the same as the DOLFINx tag e.g. v0.5.0. Git refs
should be appropriate tags for each component.
Tagged Docker images will be pushed to Dockerhub and GitHub.
docker run -ti dolfinx/dolfinx:v0.5.0
Use the Docker update stable tag workflow to update/link :stable to e.g.
v0.5.0.
https://github.com/FEniCS/dolfinx/actions/workflows/docker-update-stable.yml
Wheels can be made using the following actions:
https://github.com/FEniCS/basix/actions/workflows/build-wheels.yml
https://github.com/FEniCS/ufl/actions/workflows/build-wheels.yml
https://github.com/FEniCS/ffcx/actions/workflows/build-wheels.yml
Both the workflow and the ref should be set to the appropriate tags for each component.
It is recommended to first build without publishing, then to test pypi, then to the real pypi. Publishing to pypa cannot be revoked.
The DOLFINx wheel builder is experimental and is not used in the release process at this time.
If something doesn't work, or other issues/bugs are identified during the release process you can either:
-
Make changes on
mainvia the usual PR workflow, thengit cherry-pickorgit mergethe commit back ontorelease. -
Manually make commits on the
releasebranch.
If you want the same change to be reflected on main option 1. is preferred.
If a mistake is noticed soon after making a tag then you can delete the tag and
recreate it. It is also possible to recreate GitHub releases. However, if the
mistake was noticed after pypi packages are pushed you must create *.post0
tags or make a minor version bumps , as pypa is immutable.
Releases can be made at the following links using the appropriate tag. The automatic release notes should be checked. The release notes can still be edited after the release is finalised.
https://github.com/FEniCS/basix/releases/new
https://github.com/FEniCS/ufl/releases/new
https://github.com/FEniCS/ffcx/releases/new
https://github.com/FEniCS/dolfinx/releases/new
Check for any changes on release that should be cherry-picked back onto
main via a PR.
git checkout main
git diff release
git log
git cherry-pick 914ae4
Bump the version numbers on the main branches of UFL, Basix, FFCx,
DOLFINx following the instructions above.
Bug fix versions e.g. v0.5.1 can be made by cherry picking commits off of
main and bumping the minor version number. Remember to run the DOLFINx
integration tests on a proposed set of tags as it is easy to make an error.
Contact Drew Parsons.
Conda Forge bots typically pickup new releases automatically. Can also contact @minrk.
Update the Spack recipe for the FEniCSx components on the fork
FEniCS/spack using a branch e.g.
updates/dolfinx-<version>. Create a pull request to the Spack mainline
repository.