Looking for an analog of a Chem developer's tag

[mmanyin]

In the past, when a new feature has been added to Chemistry, it has been announced at the next monthly CCM meeting, with the latest CVS tag (created by the Chem gate-keeper) for users to check out. We need a corresponding capability in Git. With the current workflow, new functionality gets incorporated into the Chem "development" branch, and then at a later date it is merged into Chem Master. Then that version must be specified in the configuration under the master GCM. I'm worried that this process will be quite a bit slower than before, going from weeks to months. Can this be remedied? (Or are my fears unfounded?)

[tclune]

@mmanyin For the moment, you are the gatekeeper on the protected branches of this repository, which makes it a bit surprising that you would worry about the propagation being too slow. You control the pace!

Presumably the underlying concern is that people want to play with the new feature before it is sufficiently validated to placed on master. The usual recommendation for this is to use a feature branch for the specific feature under discussion. The point of the develop branch is to accumulate such features prior to some validation point at which time things are on master (and presumably tagged).

If someone wants to combine multiple features prior to their being integrated onto the master branch, then they would merge 2 or more feature branches in their sandbox. Not hard, but not quite black-box simple either. (Could possibly script something in parallel build that supports this down the road.)

We should discuss this further.

[mmanyin]

To clarify, I was concerned with the pace at which the black-box user could gain access to new functionality, assuming that meant the new code would need to be merged into the Chem Master branch, tagged, and then set as the default in the GCM Master Branch (out of my control). If the chemistry users are more Git-savvy, then it may suffice for me to issue a new master tag for GEOSchem_GridComp, and the users can edit the proper Externals.cfg to get access to that functionality.

As @tclune points out, new functionality could instead be made available to users through feature branches, or the Develop branch. A concern with Develop would be its "unstable" nature. Stable feature branches could work, if users could access them from github, but those would not be as permanent as official tags. (Feature branches get deleted eventually, right?)

[tclune]

Yes - in general if users/developers want access to features before they appear as defaults in the main GCM fixture, then they must understand enough manage-externals to make that happen. Or someone such as yourself would need to create additional feature branches on the higher level repos that point at the new features. E.g., we could add a CCM.cfg file in the GEOSgcm repo, and that config would specify a CCM tag/branch for the features that should be exposed to that community.

If you decide to use tags, let's discuss some convention for the names. I've already forgotten what I recommended in the training, but I suspect it is inadequate for this situation.