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 https://docs.fenicsproject.org.
The release proceeds in a bottom up manner (Basix, UFL, FFCx, DOLFINx). GitHub Releases and 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.
The release process consists of the following steps:
- Update version numbers and dependencies on the
release
branches. - Run integration tests, ensuring that the
release
branches work together. - Make git tags on the tip of
release
. - Organise production of release artifacts.
- Update version numbers on
main
. - Make GitHub and 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
main
intorelease
resolving all conflicts in favour ofmain
.git pull git checkout release git merge --no-commit main git checkout --theirs main . git diff main
-
Update version numbers, e.g.
python3 update_versions.py -v 0.5.0
-
Inspect automatic version updates.
git diff
-
Commit and push.
-
Check
git diff origin/main
for obvious errors.
-
Merge
main
intorelease
resolving all conflicts in favour ofmain
.git pull git checkout release git merge --no-commit main git checkout --theirs main . git diff main
-
Update the version number in
setup.cfg
, e.g.2022.2.0
. -
Commit and push.
-
Check
git diff origin/main
for obvious errors.
-
Merge
main
intorelease
resolving all conflicts in favour ofmain
.git pull git checkout release git merge --no-commit main git checkout --theirs main . git diff main
-
Update the version number in
setup.cfg
, e.g.0.5.0
. -
Update the dependency versions for
fenics-basix
andfenics-ufl
insetup.cfg
. -
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_RELEASE
to1
. -
Commit and push.
-
Check
git diff origin/main
for obvious errors.
-
Merge
main
intorelease
resolving all conflicts in favour ofmain
.git pull git checkout release git merge --no-commit main git checkout --theirs main . git diff origin/main
-
In
cpp/CMakeLists.txt
change the version number near the top of the file, e.g.0.5.0
. -
In
cpp/CMakeLists.txt
check thefind_package(ufcx)
andfind_package(UFCx)
calls. If the DOLFINx and UFCx versions match then there is no need to change anything here. However, if they don't match, you need to manually specify the appropriate UFCx version. -
In
python/setup.py
change theVERSION
variable to e.g.0.5.0
and update the depedency versions forfenics-ffcx
andfenics-ufl
. -
Commit and push.
-
Check
git diff origin/main
for 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. 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
.
Run the workflow at https://github.com/FEniCS/dolfinx/actions/workflows/docker.yml
Tag prefix should be the same as the DOLFINx release e.g. v0.5.0
.
Git refs should be appropriate tags for each component.
Tagged Docker images will be pushed to Dockerhub.
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
.
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 pypa, then to the real pypa. Publishing to pypa cannot be revoked.
The DOLFINx wheel builder is experimental and is not used in the release process at this time.
Aside from version numbering changes, it is easier to merge changes onto main
and then cherry-pick or merge back onto release
.
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. After pypa packages are pushed you must create .post0 tags or make 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 ported back onto main
.
git checkout main
git diff release
Bump the version numbers on the main
branch.
Bug fix patches 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.