Skip to content

Release Procedure

Jump to bottom
Takahiro Ueda edited this page Feb 9, 2025 · 9 revisions

The steps for creating a new release are outlined below.

1. Check for errors on the last CI run

Ensure that all jobs in the CI pipeline for the latest commit have completed successfully without any failures.

Note: Build and test failures in the native Windows build within the Deploy workflow are currently ignored. To guarantee that Windows binaries are included in the final distribution, we need to check that the build and tests pass.

2. Create Release Notes

All user-visible changes, bug fixes and performance improvements must be documented in the Release Notes on the FORM wiki. The page title should be like Release Notes FORM X.Y.Z (e.g., Release Notes FORM 4.3.1, which corresponds to the URL https://github.com/vermaseren/form/wiki/Release-Notes-FORM-4.3.1).

3. Update the version number and date in the source code

  • sources/form3.h contains version and date information that is typically unused but serves as a fallback when non-standard build methods are employed. Ensure the following variables are updated:

    • MAJORVERSION: Represents the major version of FORM (e.g., 4 of FORM 4.3.1).
    • MINORVERSION: Represents the minor version of FORM (e.g., 3 of FORM 4.3.1).
    • PRODUCTIONDATE: Specifies the release date, used as a fallback for __DATE__.
    • BETAVERSION: Defined for beta versions. Should be undefined in official releases.

    Note that there is no PATCHVERSION variable.

  • The source files include a copyright notice. Ensure the copyright year is updated. This can be achieved by running the following command:

    ./scripts/update-copyright.sh

  • doc/form.1 (man file) also contains date information. Ensure it is updated.

4. Push a version tag

Create a Git tag and push it to the repository. Use the following format for the tag:

  • vX.Y.Z (e.g., v4.3.1) for official releases.
  • vX.Y.Z-beta.N (e.g., v5.0.0-beta.1) for beta releases.

Note that the build system relies on these version tags to set the software version.

5. Edit GitHub Releases

Pushing the version tag should trigger the CI pipeline to create a new release on GitHub Releases, including asset uploads. Edit it as necessary.

If assets are not uploaded correctly for some reason, upload them manually.

Clone this wiki locally