What is the tflite-micro version?

Skip to first unread message

Michael O'Cleirigh

Jul 27, 2021, 3:04:13 PM7/27/21
to SIG Micro

I'm building  a micropython api on top of the tflite-micro c++ api and I include a version string for the tensorflow part so the end user can know which version of tensorflow they are using.

Before the creation of the tflite-micro repository I was using the TFLITE_VERSION_STRING which was defined in tensorflow/lite/version.h as the version.

it would return something like "2.6.0".

However that file no longer exists post migration.

defined both the version string and schema version.

The schema version is now located here:

But the version string is missing.

Are there plans to version tflite-micro or should I switch gears and try to version based on the git commit id I build from.



Pete Warden

Jul 27, 2021, 8:04:22 PM7/27/21
to Michael O'Cleirigh, SIG Micro
Hi Michael,
                  that's a great question! TFL Micro has always only been loosely following the wider TensorFlow versioning process, so I think it might be more honest to use the git hash. Do you think that will be confusing to users? We're keen to support the MicroPython integration, it's a common request, so we can discuss it in more depth if you think it will be problematic.


You received this message because you are subscribed to the Google Groups "SIG Micro" group.
To unsubscribe from this group and stop receiving emails from it, send an email to micro+un...@tensorflow.org.
To view this discussion on the web visit https://groups.google.com/a/tensorflow.org/d/msgid/micro/6aef3cd8-b658-43a4-87c1-edc8e5c9ba8cn%40tensorflow.org.

Daniel Fauvarque

Oct 14, 2021, 4:07:10 AM10/14/21
to SIG Micro, SIG Micro
I have a similar issue, do you plan to tag stable releases of TensorFlow Lite Micro inline with the corresponding Tensorflow release tag ?

As an integrator, I feel more comfortable taking the same level of releases for both Gits and of course integrating what can be considered as a stable release.


Advait Jain

Oct 14, 2021, 4:50:17 PM10/14/21
to Daniel Fauvarque, SIG Micro
Thanks for the requests.

Couple of comments to illustrate where we are at w.r.t. releases:
  • There isn't any mapping between TF versions and TFLM. TFLM only supports a subset of the functionality in TF and that will continue to be the case. As such, the separation of TFLM into its own repository helped make this explicit.
  • While adding a tag to the TFLM repository is feasible, there aren't any additional tests that we would do (on top of what we have as part of CI).
  • We currently only make bug fixes on the main branch, so a tagged release will basically be a snapshot in time with no updates.
  • The optimized kernel implementations are a very important part of TFLM and having a TFLM release would require a coordinated effort with the maintainers of the optimized kernel implementations which is not resourced at this time.
We would be happy to learn more about what users would expect to see from a release as that might help change how we think about this in the future.

Daniel Situnayake

Nov 11, 2021, 6:17:50 PM11/11/21
to SIG Micro, Advait Jain, SIG Micro, dfau...@gmail.com, Kwabena W. Agyeman
Hi SIG members,

Kwabena from OpenMV and I recently wrote up an argument for bringing versioning to TFLM. You can find it in this document:

We've been chatting with Pete and Advait on the TFLM team and it sounds like there aren't any plans to start versioning any time soon, but Advait recommended sharing our document here for broader discussion.

Advait mentioned the work around moving hardware-specific code out of the main repo as a reference point:

The idea is that we could put our integrations in a separate repo with CI that can be used to understand when changes cause problems. I think this is a good approach generally, but I'm not sure it will help with API breakage, since with the integration code in a different repo the TFLM team won't "feel the pain" of breakage until the changes have already been submitted.

Big thanks to Pete and Advait for engaging with our discussion so far. Would love to hear the community's thoughts on this issue!


Daniel Situnayake

Nov 18, 2021, 12:52:30 PM11/18/21
to SIG Micro, Daniel Situnayake, Advait Jain, SIG Micro, dfau...@gmail.com, Kwabena W. Agyeman
Fredrik just added a great suggestion to the document:

  • Numerical consistency between TFL and TFLM runtimes. It would be great if an end user could be guaranteed that the TFL runtime of a given version matches (numerically) a certain version of the TFLM runtime. It would be sufficient to limit this numerical aspect to the behavior to reference kernels, since optimized kernels may behave differently. For example: “TFL x.y.z matches TFLM x.y.z”, or “TFL x.y.z matches TFLM a.b.c”
This is definitely something a lot of people have asked us about (e.g. which TFLM "version" is compatible with which TensorFlow/TF Lite version).


Reply all
Reply to author
0 new messages