Which strategy to manage production branches?

[marcodelapierre]

Writing some thoughts down, following the useful discussion with @pelahi today!

The current branch convention was put in place by me, without others' inputs. It would be good to revise, to find one that is possibly better, and also works for the whole team.

Context: on Setonix we have full stack rebuilds every X months. Each build has a DATE_TAG of format yyyy.mm, for instance 2022.05.

Current idea: to have the main branch, plus a 1:1 match between deployment cycle (DATE_TAG on Setonix) and a branch with the same DATE_TAG. In addition, version+revision tags within DATE_TAG branches can be used to flag milestone states of the deployment. The main branch is actually used as a "develop" branch, as it is used to progress the development of the repo, both for the current and for future deployments. The DATE_TAG branch for the current deployment only gets commits for fixes, adds and edits required by the current deployment (typically a subset of all commits that go on main). Only one DATE_TAG branch is actively maintained at any given time: older versions are not maintained, and a new branch is created only when a new deployment happens, and the previous gets obsoleted.

I borrowed the above structure from the Spack project. My main thought was the need to be able to maintain the current deployment cycle, while at the same time develop features for future deployments. The typical use case is starting to work/test the next Spack (or, to a lesser extent, SHPC) release. In addition, as we progress during a stack build (deployment) life cycle, the needs of the current and future deployments may increasingly differ, and so may the required commits. This branch setup enables to keep adding fixes/edits to the current branch, with no strict need to merge back to main: when the current deployment is gone, the corresponding branch simply becomes unmaintained.

Technical note: right now, commits that need to go both on main and the current DATE_TAG are passed from one to the other, one by one, by using git cherry-pick <commit id>.

However, there may be better ways of organising this...

Happy to collect thoughts from the team here!

[dipietrantonio]

Hi Marco, sorry for the delay in replying to this. That is how it should work in theory. In reality, we are not going to redeploy the same branch twice. Once we deploy the "main", which is then branched/tagged to a specific date, these things will happen:

• any update is done live using the spack user, and
• if the change is useful for future deployments, it is implemented in the main branch.

I do not see the reason to choose to redeploy a maintenance branch versus the main branch (which becomes a new DATE_TAG deployment).

Any modification that is limited to a specific deployment won't be really pushed to the repo.. especially when you potentially have multiple people working on the stack.

What do you think? Also tagging @pelahi

[marcodelapierre]

I think the strategy you outline makes sense, and can be reasonably implemented. Thank you!

[dipietrantonio]

@pelahi If you agree on the approach I outlined, we can close this issue (and add this to our README).

[halfflat]

There's one issue I can see with only putting updated recipes on the main branch: if we edit a recipe targeting a deployed stack version, it may only function with the version of spack in that deployed stack, and not the version targeted with main. We'd then have a modified package installed without the corresponding recipe being in revision control.

My preference would be that any updates on a deployed software stack go through a PR on the corresponding branch so that the changes and review are visible and persistent, and then once merged, deployed live. If it's a change that should be reflected on the main branch too, then it should also be applied as a separate PR on main. The review process on this second PR will be straightforward if no alterations were necessary.

[pelahi]

I'm happy to close the issue @marcodelapierre @dipietrantonio. Though I take your point @halfflat .

[marcodelapierre]

👍