Work out branching and tagging organization for this repository

[billsacks]

This repository contains images used in the CTSM documentation. Its purpose is to keep possibly-large image files out of the main CTSM repository, to avoid bloating that repository - since the vast majority of people cloning CTSM won't need access to these images.

However, as the documentation evolves and diverges on the various CTSM branches (master, release-clm5.0, etc.), presumably this repository will also evolve and diverge. So we'll need to come up with a branching strategy. One obvious choice would be to have branches here that mimic the main branches in the CTSM repository (for now, master and release-clm5.0).

Also: The main CTSM repo will point to versions of this repo, which it will pull in via manage_externals. We may want to introduce a tagging convention in this repository so that CTSM can point to logically-numbered tags rather than arbitrary hashes. I'm struggling a bit with what would be the best approach for that. Some options I could imagine are:

• Sequentially numbered tags for each branch, such as master_v1, master_v2, etc. (though we may want to have some fairly large number of leading 0s to maintain numeric ordering as these version numbers go up in orders of magnitude)

• Some relationship between the tags here and the tags in the main CTSM repository. A tempting suggestion is: the tag in this repository should correspond to the first tag in the CTSM repository that uses this version of the images repo. However, that introduces a chicken-and-egg problem, since we need to make the tag of the images repo before we can tag the CTSM repo, and it's sometimes hard to guess exactly what the relevant tag in the CTSM repo will be (because there may be other CTSM tags that come before the one you're working on). An alternative could be to tag this images repo with one of the last CTSM tags that didn't use this version of the images repo; trying to get the exact last CTSM tag would have the same chicken-and-egg issue, but if we aren't shooting for perfection, this could be a "close-enough" solution. It does raise the possibility that we'd have a second tag for which we'd want to give it the same name (if going through multiple iterations of documentation revisions without making a CTSM tag), though we could add something on to the end of the tag name in these (probably unusual) cases.

@ekluzek I'd invite your thoughts on this. However, I don't think it's urgent. For the first iteration, unless we come up with something we're happy with, I'm thinking I'll just point to a hash in this repo, and then we can revisit it down the line.