Policy for Patches

1. General Policy
2. Technical Information

1. General Policy

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.

2. Technical Information

• 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.
• The release coordinator creates a branch tag in CVS, based on the tag of the release to be patched. The branch tag is of the form geant4-XX-YY-patches_branch; the branch will remain valid for any future patches to be applied to that release.
  Example:
  • geant4-09-02-patches_branch 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.
• 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.
  Example:
  • Check out the whole geant4 source code tree updated to the branch tag:

               cvs checkout -r geant4-09-02-patches_branch geant4
            

  • Implement the fix in the code and commit as usual.
• A tag of the form category-name-VXX-WW-ZZ has to be provided to STT as normal practice foresees, where ZZ is the last increased number for that category in the previous release series WW.
  Example:
  • Tag the committed code for the release 9.2 series (numbering should refer to the previous release to differentiate from the development in the main HEAD trunk or in the subsequent release):

               cvs tag emstand-V09-01-23
            

  • Propose the tag to STT in Bonsai as usual, possibly mentioning that the tag is meant for the patch release 9.2.p01.

NOTES

1. In order to synchronise with fixes introduced in other categories in the branch tag, it will be required to apply an update from time to time; i.e.:

              cd $G4INSTALL
              cvs update
       

   and verify that the tests give the expected results...
2. An already existing development tag including just fixes which you wish to provide in the patch, can be imported in the branch tag for the patch as follows:

              cd $G4INSTALL/source/digits_hits
              cvs update -kk -j digits_hits-V09-02-00
       

   You should resolve any CVS clashes which may be reported, then update the History file, commit the imported/modified files to the branch, and tag:

              cvs commit -m "Merged files from digits_hits-V09-02-00"
              cvs tag digits_hits-V09-01-11
       

3. Once all fixes for the patch are committed and the patch is finalised, is is important to remember to update the tree to the sticky tag which will be created for the patch; i.e., abandon the branch to avoid easy mistakes:

              cd $G4INSTALL
              cvs update -r geant4-09-02-patch-01-ref
       

4. Fixes committed to the branch for a patch may in case also be committed on the HEAD of the main trunk for future releases.
   It is suggested to do this in a separate source tree dedicated to the current development.