Difference between revisions of "HOWTO Create a New Hall D Software Release"
(→Instructions updated 04/07/2022) |
|||
| (5 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | === Instructions updated | + | === Instructions updated 24/04/2023 === |
''' 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 ( | + | '''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 | ||
| Line 32: | Line 32: | ||
</pre> | </pre> | ||
| − | '''7)''' Log into | + | '''7)''' Log into halld-cron as gluex (from behind scilogin) |
<pre> | <pre> | ||
| − | ssh gluex@ | + | ssh gluex@halld-cron |
</pre> | </pre> | ||
| − | '''8)''' Change into the directory | + | '''8)''' Change into the chore directory |
<pre> | <pre> | ||
| − | cd ~/chore | + | cd ~/chore |
</pre> | </pre> | ||
| Line 49: | Line 49: | ||
'''10)''' Check log files. If one build fails, relaunch '''9)''' after all processes finish. | '''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 | + | '''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.
