10. Release Process and Checklists

Release goals

A release candidate should satisfy:

  • stable C++ core behavior for supported surfaces

  • C ABI behavior consistent and tested

  • Python and Fortran bindings build and pass expected test gates

  • docs site and API references build successfully

Contributor release checklist

Build and tests

  • [ ] build core/bindings with -j6

  • [ ] C ABI tests pass

  • [ ] Fortran basic test passes

  • [ ] Python non-MPI/non-CUDA suite passes

Documentation

  • [ ] Doxygen generation succeeds

  • [ ] Sphinx site generation succeeds

  • [ ] new contributor-facing pages are in docs navigation

  • [ ] distributed_span coverage is present in user/developer/bindings guides where non-owning semantics are relevant

API quality

  • [ ] public API comments complete and signature-aligned

  • [ ] backend-unavailable paths return explicit status codes

  • [ ] ownership/lifetime contracts documented for new handles/wrappers

  • [ ] parity matrix rows are updated for any changed container/view semantics (including distributed_span)

Version and packaging notes

  • keep package version sources aligned (CMake/package/binding expectations)

  • avoid hardcoded test expectations that diverge from project version metadata