Recent backwards-incompatibility in cime for user-defined machines

[billsacks]

This is for discussion - in this issue and/or at our next cime telecon.

I just stumbled across a cime change that was made a few months ago that requires changes in the config_compilers.xml file that any external users maintain on their own machine: #3054 changed the compile_threaded value from lowercase ('false') to uppercase ('FALSE'). @jgfouca did a good job of calling this out in the PR description, but I wonder if we need to do more than that in the future to minimize or eliminate the burden that such changes place on external users, given that we're trying to keep cime easy to port to other machines.

I'm not quite sure what the answer is here. Ironically, this PR came in right before we discussed the issue of backwards-incompatible changes (https://github.com/esmci/cime/wiki/Meeting-Notes#apr-3-2019), but I don't think we thought of this given change as backwards-incompatible at the time. After experiencing the problems caused by this on my own machine (which I just ran into now because we just recently updated our cime version in CTSM), I see that any changes that force users to change their config_machines or config_compilers files should be considered backwards-incompatible.

@jgfouca @jedwards4b @mvertens @rljacob @fischer-ncar

[rljacob]

Note: " maintain on their own machine" means config files kept in a ~/.cime directory.

[rljacob]

Discussion from telecon: We need to recognize that any PRs requiring changes to machine config files introduces backward incompatibility. And we then need to publicize that so people can change their .cime/config files.