Decide how to follow the latest MicroPython

[wnienhaus]

Today, our build process build MicroPython using the lastest state of master of the MicroPython repository. This is great, because it suggests that our code (as exercised by our tests) works with the very latest MicroPython.

However, or when the MicroPython makes changes to their build process, it can break our build (as it did, see #81).

Perhaps we can find a better way to "track" or "follow" the latest MicroPython, while still retaining control over our build process.

Likely acceptance criteria of any improvement:

• Keeps our build working, even when the MicroPython project makes changes to their build process.
• Allows us to choose when to adapt our build process to the latest MicroPython approach
• Keeps it easy (or automated?) to keep our build close to the latest MicroPython
• Keep some way (even if limited to a local machine) to run against the very latest MicroPython to test/fix our build process.

[wnienhaus]

(to keep all the discussion together here) In #82, @mattytrentini suggested:

How about tagging releases in lock-step with MicroPython releases? And follow MicroPython master on this master?

[mattytrentini]

(Sorry for the delay in responding to this!)

Yes, the idea was to just tag this repository with the same tag - at the same time - when MicroPython releases. That way we can keep track of which version of micropython-esp32-ulp was current when a MicroPython release was made. If multiple releases are applied to the same version here I don't see that as a problem.

An alternative may be to add this as a submodule to MicroPython (for at least some of the ESP32 builds it makes sense to include this) and ensure that the submodule is tagged along with the rest of the release.