Release Readiness Checklist

This checklist captures the release expectations that matter most for Buffalo Core as a foundational dependency.

Goal

Buffalo Core should remain small, stable, and predictable for downstream Buffalo projects. Release readiness therefore focuses on public API stability and on verifying that the shared conventions still behave as documented.

Checklist

  • Confirm that the intended public surface is still limited to buffalo_core.typing, buffalo_core.numeric, and buffalo_core.diagnostics.

  • Confirm that any new public names are intentionally exported through buffalo_core.__init__ or another deliberate public module.

  • Confirm that shared type aliases and normalization helpers remain backward compatible unless the release is intentionally breaking.

  • Confirm that diagnostics codes, severity meanings, and result wrappers remain backward compatible unless the release is intentionally breaking.

  • Run ./scripts/run_checks.sh.

  • Run ./scripts/build_docs.sh.

  • Review the examples page and API guide to confirm they still reflect the intended public usage patterns.

  • If a public API change is breaking, document it explicitly in the changelog and release notes.

  • If a release includes compatibility-sensitive changes, review the release notes workflow before cutting the tag.

Breaking Changes

For Buffalo Core, the following should be treated as potentially breaking:

  • removing or renaming public type aliases,

  • changing normalization dtype or behavior in the numeric helpers,

  • removing or renaming diagnostics classes or fields,

  • changing the meaning of a public diagnostics severity level,

  • or substantially changing what is exported from the package root.