Supported ESP-IDF versions

[SergioGasquez]

Hi! At the moment we support v4.4 and v5.1 in the template. Wanted to hear your opinion about two topics:

• Shall we keep v4.4?
  • IIRC, there was some discussion of getting rid of v4.4 and its also EOL by July 2024
  • I don't have any hard preference on this topic
• Update v5.1 to v5.2
  • Since v5.2 the latest stable, I think we should probably update to it

cc: @ivmarkov @Vollbrecht @esp-rs/espressif

[Vollbrecht]

Since it is an option in the advanced template, and not the default we should maybe wait just a bit and still allow for v4.4.6 till we remove the support in esp-idf-*. Our first next goal would probably remove v4.3 stuff out of esp-idf-*

Adding v5.2 can be done when we have the next release for esp-idf-svc, as v5.2 had some api changes, this PR for example is necessary

[kassane]

My question

Does the version control of @esp-rs project just progressively follow Espressif's changes, or does it allow to keep legacy versions accessible? (LTS)

Assuming that version 5.1 has a relevant percentage of support and tools that use this version.

How would you maintain compatibility between versions when the upstream is in a much newer version with changes to the API?

[Vollbrecht]

How would you maintain compatibility between versions when the upstream is in a much newer version with changes to the API?

It depends =) In the first layer we have the direct dependency on esp-idf and the generated bindgen output. In the past we needed some rust specific patching that would not make sense to upstream. So we did it on the fly inside esp-idf-sys. This step is only because of "fundamental" problems.

Then there are general api changes and additions. The goal of our safe wrappers around the raw C api is not just to replicate the interface in most cases, but create a interface that makes more sense from a rust usage pattern. In most cases that leads to our public API to be general enough to survive underlying changes in esp-idf itself. We have lots of conditional compilation inside it to make it work, though yes its not perfect and the public API still leaks the underlying esp-idf version itself in some places.

When esp-idf introduces completely new drivers we just add it when its introduces and not backporting it. And esp-idf is stable enough that they just don't get rid of something before deprecating it. ( like the timer and rmt api's for example between v4 and v5)

Does the version control of https://github.com/esp-rs project just progressively follow Espressif's changes, or does it allow to keep legacy versions accessible? (LTS)

Currently we are testing only the latest v4 and v5 versions of esp-idf ( still transitioning to v5.2) and the git master. Technically we still could run esp-idf v4.3.x stuff but no one tested it in a long time and we marked it deprecated like have a year ago. We are not rigorous following the official release support schedule, but at least we more or less always stay on top of the latest releases. Since the esp-idf-* part of esp-rs is community driven there are also no grantees for anything here, we just do it for the fun =)