mirror of
https://github.com/vee1e/tflite-micro.git
synced 2026-09-01 17:57:27 +00:00
f4c2d0870f
Use Bazel's workspace status mechanism, designed for "stamping" builds with
identifying information from the build environment, to dynamically generate the
version label of the Python distribution package. Generate stamps when Bazel
runs via the --workspace_status_command option and command script. Then use
these stamps in the version label.
Guidelines for Python version labels are given in [PEP 440][]. TFLM does not
currently tag and publish what PEP 440 calls "final releases". Instead,
distribution packages will periodically be published from the tip of the main
branch, and users will be expected to use the latest version or pin to a
historical version of their choice. To facilitate such use, the build system
needs to generate a unique, ascending version label for each commit on the main
branch.
Guided by [PEP 440][], use developmental version labels of the form
*major[.minor].dev<time>*, for example:
0.dev20090103181505
Use a release segment with a major number of 0 (via the standard Bazel
BUILD_EMBED_LABEL stamp), because TFLM does not currently tag and publish
releases. This leaves room in the version space for making semver-style final
releases in the future. Add a developmental release segment with a date and
time stamp.
Packages should be traceable to the exact source from which they were built.
[PEP 440][] does not allow Git hashes in version labels published to PyPI;
however, the Git hash can be embedded in the package's runtime-visible
attribute `tflite_micro.__version__`, and in the package's description, which
is displayed on PyPI.
[PEP 440]: https://peps.python.org/pep-0440
BUG=part of #1484
|
||
|---|---|---|
| .. | ||
| tests | ||
| tflite_micro | ||
| BUILD | ||
| py_namespace.bzl | ||
| py_pkg_cc_deps.bzl | ||