Difference between revisions of "HOWTO Create a New Hall D Software Release"
(Created page with "== Instructions on how to create a new Hall D software release == 04/07/2022 ''' This should only be done by the Hall D software coordinator ''' ''1)''' <pre> version.xml <...") |
|||
(15 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
− | == | + | === Instructions updated 24/04/2023 === |
− | + | ||
− | 04/ | + | |
''' This should only be done by the Hall D software coordinator ''' | ''' This should only be done by the Hall D software coordinator ''' | ||
− | ''1)''' | + | '''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 | |
</pre> | </pre> | ||
− | '''2)''' | + | '''2)''' Edit file, date and description of the xml file: |
<pre> | <pre> | ||
− | + | <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> | ||
</pre> | </pre> | ||
+ | |||
+ | '''3)''' Create new releases of the relevant packages on github. The simplest way is to go through this link:<br> | ||
+ | https://halldweb.jlab.org/halld_versions/version.xml | ||
+ | |||
+ | '''4)''' Substitute new releases in xml file, removing eventual dirtags | ||
+ | <pre> | ||
+ | <package name="halld_recon" version="4.36.0"/> | ||
+ | </pre> | ||
+ | |||
+ | '''5)''' Source new xml file, e.g. | ||
+ | <pre> | ||
+ | gxenv version_5.6.0.xml | ||
+ | </pre> | ||
+ | |||
+ | '''6)''' Add dirtags for each "version mismatch found" | ||
+ | <pre> | ||
+ | <package name="hdgeant4" version="2.33.0" dirtag="hdr4360"/> | ||
+ | </pre> | ||
+ | |||
+ | '''7)''' Log into halld-cron as gluex (from behind scilogin) | ||
+ | <pre> | ||
+ | ssh gluex@halld-cron | ||
+ | </pre> | ||
+ | |||
+ | '''8)''' Change into the chore directory | ||
+ | <pre> | ||
+ | cd ~/chore | ||
+ | </pre> | ||
+ | |||
+ | '''9)''' Launch the build on 4 different machines: CentOS7, RHEL7, RHEL8 and in singularity container (also CentOS7) | ||
+ | <pre> | ||
+ | ~/bin/build_version_set_all.sh version_5.6.0.xml | ||
+ | </pre> | ||
+ | |||
+ | '''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. |
Latest revision as of 03:40, 24 April 2023
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.