Release

Release guidelines

Libraries

• tests libraries using the make check target at root level.
• be sure to merge the latest version of the Faust libraries. Check this page to possibly update libraries in several additional projects

Documentation

• in the faustdoc project, update and regenerate the faust-quick-reference.pdf file, then copy it Faust documentation folder and in FaustLive
• regenerate the Faust Compiler Options page using the make options target in this makefile of the faustdoc project (remove the options.md file to force regeneration)
• regenerate the faust2[...] Tools page using the make tools target in this makefile of the faustdoc project (remove the mkdocs/docs/manual/tools.md file to force regeneration)
• regenerate the examples pages using the make examples target in this makefile of the faustdoc project

Testing

• be sure to have compiled and installed the tools with make benchmark && sudo make devinstall
• be sure to run Box/Signal API tests
• be sure to test tests/llvm-tests and tests/interp-tests
• test all DSP samples in tests/compile-tests with make all and make release

Faust and FaustLive

• we try to release Faust and FaustLive together at the same time, to keep version coherency in the compilation chain
• all install and changelog file (for FaustLive and faustgen~) have to be checked for version number coherency before creating the binary packages

Building and testing packages (obsolete since may 2023)

• check the faustgen~ How to compile section, in particular the version numbering section.

Building and testing packages (obsolete since may 2023)

• WARNING: be sure to use a fresh clone of the release to create the macOS packages!
• on macOS, use packaging targets in faust/build, like make package and/or make release. Check with otool -L that binaries (like faust, dynamic-faust, faustgen~...) do not have local dependencies.
• on Windows (using Parallels VM) in faust/build, run MakeRelease.bat win64 (creating the win64 folder if not already existing). Be sure to synchronise the submodules (using "Submodule update" when synchronising with Tortoise Git).

Release branch (obsolete since may 2023)

A release is prepared from the master-dev branch. A release candidate branch is started:

• git checkout master-dev
• git checkout -b release-2.27.1
• git push --set-upstream origin release-2.27.1

Do some release fix commits... (that is commits that need to be part of the final published version). Create a tag (like 2.27.1-rc1) each time needed, and use the 2.27.1 tag for the final version. At some point the release can be done by merging the release candidate branch back in the master branch:

Finishing (obsolete since may 2023)

• git checkout master
• git merge --no-ff release-2.27.1

And pushed on the public repository:

• git push

And also on master-dev:

• git checkout master-dev
• git merge --no-ff release-2.27.1

Then the release candidate branch can be deleted locally:

• git branch -d release-2.27.1

And on the public repository:

• git push origin --delete release-2.27.1

Building and testing packages (since may 2023)

• the FAUSTGEN_VERSION variable has to be changed in libfaust.yml file.

• the release is built using the libfaust GitHub action. It uses precompiled LLVM and libsndfile binaries, compiles everything, creates the packages, and creates a draft release.

• associating a tag with the draft release activates it (as a prerelease). Be sure to do this association at the right time!

Release changelog

• the release changelog has three new/deprecated/fix sections filled using the GIT commit history
• the release changelog should have a special section describing the libraries