> The minimum requirement must be that they are binary and source-level > compatible. That means that no public symbols can be renamed, no public > structures can be changed, and no interfaces can be changed. So it basically > only allows private changes within the same API and non-conflicting new > APIs.
This patch worries me too much for adding to petsc 3.3 for the exact reasons Jed wrote. I strongly think it should only be in pets-dev. On second thought, after reading this patch carefully, there is a subtle but big change in functionality: the _YAML was private on purpose. The user should not have to call a whole new function just for yaml. The vision I had for Weston's code was to pass a yaml string (in hopes of command line parsing) or a yaml file to already existing functions and not have to hardcode calling yaml (or json or some-future-thing). If this patch could be reworked to have passing a yaml file to PetscOptionsInsertFile (so that yaml could be in ~/.petscrc) then I would be +1 for that patch. As is, I'd rather keep the current code and try to fix it so that _YAML was still private and that current functions (PetscOptionsInsertFile, etc.) could parse yaml.
