Selection of Git development model and releases.

[jdeaton]

In order for my MAST spack package to work as designed and be pulled into the mainline spack repository, we need to define version numbering for MAST. I think now is also a good time to try to migrate some of the recent work back into this repository and come up with a branching/pulling strategy to incorporate stabile capabilities into releases.

As far as I can tell from reading around, a good version strategy is A.B.C where A involves major API breaking changes, B adds functionality, and C are hotfixes. Perhaps a good 0.X.0 (start X at whatever number you want) release would be to incorporate the refactored CMake build system with 3 simple examples (same problem, first do analysis, then do direct sensitivities, then adjoint sensitivities). For the 0.(X+1).0 release we can simply add more examples.

I did some searching and it seems like there are various strategies for using branches to collect commits/features into releases and manage incorporating bug-fixes.

• GitHub Flow: https://guides.github.com/introduction/flow/
• Git-flow: https://datasift.github.io/gitflow/IntroducingGitFlow.html, https://nvie.com/posts/a-successful-git-branching-model/
• Forking Workflow: https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow (based on Git-flow with GitHub forks)
• Forking Workflow (without develop branch): https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

I think one of the last two looks like it might work best.

[manavbhatia]

I think the basic idea is to do all the development in other branches and merge them back to the master after testing. The second one is talking about a develop branch, which I don't like. I would prefer a master branch which is tagged for version release based on a suitable schedule.

[jdeaton]

I wanted to revisit this issue now since there are definitely multiple folks working on MAST and @JohnDN90 and I have been working along with pull requests for some time now. I think based on what we have been doing the last workflow listed

• Forking Workflow (without develop branch): https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

is what we should stick to (its close to what we've been doing already).

The only thing that isn't described well in the article is what to do when master has changed a lot since your feature branch was forked. In this case, you just need to either:

• merge master -> your feature
• rebase your feature on top of master and force push back to your feature branch

@manavbhatia if you are agreeable, I'll add a page to the documentation that tries to describe the suggested workflow with some illustrations.

The other thing is we need to decide is releases. We have quite a few things we've added/updated/changed (on our repo) and we need to prioritize getting them into master on GitHub and where we might want to break releases at. I think we can use the "Projects" feature on the top-level MASTmultiphysics organization/team to do this planning (https://github.com/orgs/MASTmultiphysics/projects).

[manavbhatia]

@jdeaton I support both ideas and the forking workflow also conforms to my preferred workflow concept.

Let me know when you and @JohnDN90 are ready to identify all new components that you intend to commit to the repository. I can do the same at my end, and we can chalk out a release schedule.