Difference between revisions of "HOWTO Create a New Hall D Software Release"
(→Philosophy for Version Numbering) |
(→Instructions updated 04/07/2022) |
||
Line 3: | Line 3: | ||
''' This should only be done by the Hall D software coordinator ''' | ''' 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.: | + | '''1)''' Start with the previous release, usually linked to version.xml. Increment one of the numbers (major, minor, bugfix [https://halldweb.jlab.org/wiki/index.php/HOWTO_Create_a_New_Hall_D_Software_Release#Philosophy_for_Version_Numbering]), e.g.: |
<pre> | <pre> | ||
cp version_5.5.0.xml version_5.6.0.xml | cp version_5.5.0.xml version_5.6.0.xml |
Revision as of 10:46, 8 April 2022
Instructions updated 04/07/2022
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 sandd1 as gluex
ssh gluex@sandd1
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.