Run5 naming conventions
we have a well defined and established rule for 'tagged' versions of lhcb and components and a good latest combination for run3/run4/run5 but we are now faced with the issue of having to support not only fixed versions for components but also evolving parallel changes for a given detector for run3 and run5 or within run5.
For the lhcb/top level, we have runx/trunk
, where trunk
means the working branch, however in Run5 there will be several working version in subdetectors, then trunk
does not work then. We agreed to have 'branches' for run5 components to allow continuing development and reserve trunk for run3 development.
We should have naming convention for branches so that they can be identified and the same rules applied to trunk in term of checksums can be used, creation of version tags, etc. We can have more then one branch for different run5 options that need to be maintained, as for example for FT, TV, MP and UP. We should avoid using vXX.yy
for these evolving branches: that is reserved for the frozen version snapshots. The name should start with branch
(similar to the old svn code management system).
We would have:
- for Run3-only detectors
- VP/trunk
- VP/2024.Q1.2.v01.00
- for Run3 & Run5 detectors
- FT/trunk
- FT/2024.Q1.2.v01.00
- FT/branch-run5-xxx
- FT/run5.v01.00 (for a version for run5 from above)
- for Run5-only detectors
- MP/branch-run5-xxx
- MP/run5.v01.00 ...
And under run5 directory we would have:
- run5/proto-v01.00 ...
For the first round, we call branch-run5-baseline
for FT, TV, MP and UP to not block the development in !568 (merged), but we should discuss with new sub-dectors about the name for the next round of names. Like for FT in run5, we can call it FT/branch-run5-smallhole
or something else. Please let us know your opinions or thoughts on that, thanks!
@gcorti @tlatham @bcouturi @mwhitehe
UP group: @xuyuan @peilian @fanjie
TV group: @tlatham @dathomps @tevans
TORCH group: @kreps
CALO group: @dzuliani @jmarchan
Please feel free to cc people who you think should be involved in this discussion but whom I might have missed