HOWTO Create a New Hall D Software Release
Instructions updated 24/04/2023
This should only be done by the Hall D software coordinator
1) Start with the previous release, usually linked to version.xml. Increment one of the numbers (major, minor, bugfix ), e.g.:
cp version_5.5.0.xml version_5.6.0.xml
2) Edit file, date and description of the xml file:
<gversions file="version_5.6.0.xml" date="2022-04-07"> <description>Update releases of amptools, halld_recon, halld_sim, gluex_root_analysis, and hd_utilities.</description>
3) Create new releases of the relevant packages on github. The simplest way is to go through this link:
4) Substitute new releases in xml file, removing eventual dirtags
<package name="halld_recon" version="4.36.0"/>
5) Source new xml file, e.g.
6) Add dirtags for each "version mismatch found"
<package name="hdgeant4" version="2.33.0" dirtag="hdr4360"/>
7) Log into halld-cron as gluex (from behind scilogin)
8) Change into the chore directory
9) Launch the build on 4 different machines: CentOS7, RHEL7, RHEL8 and in singularity container (also CentOS7)
10) Check log files. If one build fails, relaunch 9) after all processes finish.
11) Update the soft link to version.xml in the halld_versions repository on github. A cronjob on sandd1 will synchronize the group disk at midnight.
Philosophy for Version Numbering
(proposed by Mark Ito)
version_3.2.1.xml, 3 is the major version number, 2 is the minor version number, and 1 is the subminor version number
The major version number changes when there is a fundamental change in philosophy, a change which breaks backward compatibility in a significant way, or marks a milestone that we want to see clearly in the version number. For example, halld_recon 4.0.0 was the first release with DIRC software in it. version_5.0.0.xml was a version set where several support packages changed, including the big jump from ROOT 6.08 to 6.24.
The minor version number change is the standard version change; there is new stuff and we need a new release with the new stuff.
The subminor version changes when the previous subminor version has a bug that needs to be fixed to provide the functionality intended with the previous minor version change, i.e., we tried to make a functional change but something was wrong in how it was implemented, i.e., a bug-fix release. It does not mean that the increment only contains a small number of commits. Even a small number of commits (even one commit), can signal an intentional change in behavior in which case the minor version number should be incremented. For example halld_sim 4.9.1 did the same thing as halld_sim 4.9.0, but was tweaked to work with older versions of halld_recon.