HOWTO Create a New Hall D Software Release

From GlueXWiki
Jump to: navigation, search

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 [1]), 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:
https://halldweb.jlab.org/halld_versions/version.xml

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.

gxenv version_5.6.0.xml

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)

ssh gluex@halld-cron

8) Change into the chore directory

cd ~/chore

9) Launch the build on 4 different machines: CentOS7, RHEL7, RHEL8 and in singularity container (also CentOS7)

~/bin/build_version_set_all.sh version_5.6.0.xml

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.