How do we deal with new/future software?
The new software installation cycle dictates new software only in April and October. Thus, we should also plan ahead the documentation of the software accordingly. In April, the module development/24.04
is renamed to release/24.04
, I assume. Thus, if we document software with development/24.04
, we need to change it in April again. Alternatively, we could directly use release/24.04
and postpone the publication of the changes. This would require the following steps:
- Add a new
next-release
branch, where we prepare changes in software documentation that need to be made once the new release is out. - Then, we can merge it to
main
at the same time we make the new release available on all clusters (or topreview
one week in advance when we want to look at it earlier). - We could automate this merge with pipeline schedules if we know the exact date.
- We need to document the approach in the contribution guide, so that contributors select whether it is an urgent change (MR with target
preview
) or a planned change (MR with targetnext-release
). - We could use the half-yearly checks to also look for old releases and update if required.