Come up with a system for tracking GCAM compatibility

[pralitp]

As will continually happen, updates in GCAM such as library version updates will create incompatibilities in gcamwrapper. It has already happened with TBB/Eigen and will again for RapidXML.

We should come up with a policy about maintaining backwards compatibility and then a strategy for how exactly to do that from a branching perspective.

[crvernon]

@pralitp Agreed, I think containerization will help with this naturally from a deployment perspective. From a depreciation perspective, we may have to set up a pretty extensive actions suite that runs according to a cron job weekly to ensure that our versions don't break with new releases. Versions that do break will need to have breaking libs versions pinned or set to <= the working version.

From a branching perspective, I think we can still run with (fully open to discuss and find what is best for this repo):

• main as the current stable version for which a release always exists. This never gets a commit that is not a release. Main can get a hotfix but it has to be immediately released.
• dev the next pending version to be released. All feature and bug fix branches that are not hot come off of this one.
• gh-pages our docs that get auto-deployed along with a merge to main via an action.

[pralitp]

Thanks Chris. I think this makes a lot of sense. And as I think about it I think some of these issue are coming up because we are still very much in the development phase of gcamwrapper so we have entire features that are yet to materialize. BUT we want to use them on older workspaces. That being said, "compatibility" is going to get even more tricky once we add the query library as sectoral representation and names are more frequent to change.

Thus, in addition to your suggestion above, I think:

• In the short run I will just drop some tags to help people (me) figure out how to get back to a working version at some point in time. This helps support older branches with which we may want to use gcamwrapper.
• In the future we will maintain a submodule pointer in GCAM itself to a compatible gcamwrapper. To support this we will want to set up some tests on the GCAM side to know when gcamwrapper queries break.

Given the second bullet is a bit aspirational / harder to do I'm going going to leave this issue open for now to have a space to keep thoughts as we go to implement it.