Versioning

This project follows Semantic Versioning (MAJOR.MINOR.PATCH):

  • MAJOR: a breaking change. A public method or parameter is removed or behaves incompatibly, or support for a previously working environment is dropped.
  • MINOR: a backwards-compatible addition (a new method, parameter, or supported model type).
  • PATCH: a backwards-compatible bug fix.

Where the version lives

The version is defined in exactly one place: __version__ in src/__init__.py. setup.py reads it from there at build time, so don't write the version anywhere else.

Changelog

Every user-facing change is recorded in CHANGELOG.md at the repo root, mirrored verbatim to source_docs/changelog.md (the docs site's Changelog page). The two files must stay identical.

  • Add the entry in the same PR as the change, under the header for the next release.
  • Group entries under ### Added, ### Changed, ### Fixed or ### Removed (Keep a Changelog).

Release process

  1. Check the next version's changelog section covers everything merged since the last release.
  2. Bump __version__ in src/__init__.py.
  3. Replace Unreleased in the changelog header with the release date (in both files).
  4. Commit to main.
  5. Tag and push: git tag v1.3.0, then git push origin v1.3.0.
  6. Create a GitHub Release from the tag, with that version's changelog section as release notes. Publishing the release runs publish.yml, which builds the package and publishes it to PyPI with Trusted Publishing. The trusted publisher on PyPI must name workflow publish.yml and environment pypi.
  7. Verify that the PyPI page shows the new version and pip install --upgrade teachable-machine-lite picks it up.

The docs site redeploys automatically (docs.yml) on every push to main that touches source_docs/, src/ or mkdocs.yml.

Regenerating the test models

The small models in tests/fixtures/ are generated by a script that needs TensorFlow:

pip install tensorflow
python tests/fixtures/make_models.py