[petsc-dev] Understanding Vecscatter with Kokkos Vecs

[Barry Smith]

  Using the git history one can presumably get the version a function was introduced (appeared in the source). Changes are a bit trickier but I guess one could take the current function, march back in time in git until there is a diff appear. Of course many diffs are trivial. In theory one can list each set of changes for each function. 

 Except when people mess up the history cutting and pasting and changing the cut code instead of the paste code. (Is there a way we can detect this and reject such MR?).

Barry


> On Feb 19, 2021, at 1:44 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Patrick Sanan <patrick.sanan at gmail.com> writes:
> 
>> Aside: it's been on the list of good things to do, docs-wise, to be able to label parts of the API as more or less stable, so I'm hoping we'll get to that (though I think it makes sense to wait until we've finished some of the current migrations tasks).
> 
> Yes, I would love to have version introduced, version changed, and stability level as structured information for each function. Ideally, with tooling to alert when changing "stable" interfaces and to make clear to users when they are using interfaces that are not stable.
> 
> Rust is a strict demonstration of this, with features limited to "nightly" (inaccessible with any flags when building with stable Rust) until they stabilize (if ever).