Updating Workflow: adding a dev branch

[pearsonca]

Per discussion at the flepimop meeting, we need to do setup for the new workflow.

Briefly, commits "main" will only correspond to "releases", which will either be hotfixes (e.g. addressing some bug) or periodic updates (corresponding to an interface changes, breaking or not).

any "operational" activity (e.g. an SMH round submission, or some paper-oriented project, or some ad hoc STLT partner analysis, etc) should be against a particular release tag on main. if there are any library updates needed to support that work, there should be one branch for that activity.

"dev" will correspond to the current "release candidate"; basically, the periodic merges from dev into main will correspond to releases. new features should be made as branches off dev and then merged when complete. after an operational activity completes, any ad hoc branch with new features should be reworked as a branch off dev, cleaned up, and merged. On the next release cycle, that operational work should confirm that the new release reproduces the previous results with the capability now incorporated (though this may entail changes to how that work leveraged the library).

@TimothyWillard has added a dev branch, and we're looking at redirecting PRs to that branch.

@shauntruelove @jcblemai we may need to modify the branch protections to address this new workflow.

See this diagram for an illustration of the workflow.

[TimothyWillard]

I think it could be helpful to come up with a convention for naming branches to make it easier to identify and find them. I understand that going back and applying it to the current branches is more work then its worth, but going forward:

• Operational work goes into branches prefixed with operations/. Maybe someone from the ops side would have more insight into whether it also makes sense to include the cycle/disease/other meta into the branch name.
• Feature work goes into branches prefixed with feature/ and I would also go further to suggest feature/<GitHub issue number>/<short name> to make it easy to tie feature branches back to an issue (although not tied to that).
• Hot fixes go into branches prefixed with fix/ or hotfix/ (fine with either), probably doesn't make sense to tie to a GitHub issue always since we may not make one until cleaning it up for a feature.

Thoughts? I'm happy to incorporate where we land into GH-370.

[pearsonca]

those seem roughly fine to me.

Thinking aloud: we don't necessarily need an ops branch until adhoc modifications required, but we also want a singular one when we do, irrespective of how many distinct ad hoc mods needed.

Maybe we ought to keep a single issue tracking all the stuff that is going into that ad hoc branch, and so perhaps the ops branch would also have an associated github issue which lists e.g. which dev feature branches have been pulled in, which totally ad hoc stuff added, etc. Not the standard one-problem-one-issue, but seems distinguishable to me.

[TimothyWillard]

Closing as done and documented in GH-370. Further changes to the workflow should be discussed in follow up issues.