Policy for patches

The information in this document in good part reflects and extends the Tag & Release policy document of Geant4.

General Policy

The following points applies when a patch to an existing Geant4 release is made:

1. Patches to the more recent public releases of Geant4 are provided according to the number and importance of fixes available.
2. Patches should ONLY include fixes, no new features, classes or interface changes.
3. The decision if and when to deliver a public patch is taken by the release team in consultation with the STT and the Category Coordinators involved.
4. The approximate date for the release of a patch is announced to the SB by the release coordinator as soon as it can be established.
5. Q/A and validation tests are performed as for a public release.
6. A patch is announced by the release coordinator to the user community as for a public release; source code and binary libraries distributed from the Web are updated accordingly.

Technical Information

1. A release patch tag is identified by tags of this format:

    geant4-XX-YY-patch-ZZ
   

   where:

   • XX-YY refers to the latest minor public release
   • ZZ is the patch release number, which is incremented sequentially and reset at every new major/minor release.

   A patch tag should not include the system tests directory and the categories’ unit tests directories.

   Example:

   • geant4-09-02-patch-01 identifies the first patch applied to release 9.2.
   • geant4-09-02-patch-01-ref identifies the corresponding development tag, which includes also the system tests not distributed in the public release.

2. The release coordinator creates a patches branch in the repository, based on the tag of the release to be patched. The branch tag is of the form geant4-XX-YY_patches; the branch will remain valid for any future patches to be applied to that release.

   Example:

   • geant4-09-02_patches is the branch tag created starting from geant4-09-02-ref-00. Fixes committed in this branch will form release 9.2.p01, and, later on, any other future patch on release 9.2.

3. Fixes to be provided as a patch to an existing release XX.YY[.pKK] should be implemented and committed by category coordinators to the specific branch-tag, under the supervision of the release coordinator.

   Example:

   • Check out the whole geant4-dev source code tree updated to the branch tag:

    git checkout -b run-V10-04-03 upstream/geant4-10-04_patches
   

   • Implement the fix in the code, commit and create a Merge Request to happen in the branch of the patch.

4. A tag-ID of the form category-name-VXX-WW-ZZ has to be provided as normal practice foresees, where ZZ is the last increased number for that category in the previous release series WW.

   Example:

   • Provide a Tag-ID for the committed code for the release 10.4 series (numbering should refer to the previous release to differentiate from the development on the Master or in the subsequent release):

    emstand-V10-03-23
   

   • Submit the Merge Request as usual, but - specifying the branch of the patch - where to merge the fixes.

NOTES

Details on the procedures for contributing to the GitLab repository can be found in GitLab, and in particular in the session “Preparing and Submitting Patch Merge Requests”. Fixes committed to the branch for a patch may in case also be merged on the Master for future releases. It is suggested to do this in a separate source tree dedicated to the current development.