Skip to content

Release Procedure

Jump to bottom
Takahiro Ueda edited this page Nov 16, 2024 · 4 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.

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).

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.

5. Edit GitHub Releases

Pushing the version tag should trigger the CI pipeline to create a new release in the GitHub Releases, including uploading assets. Edit it as necessary.

Clone this wiki locally