MicroPython
MP from 1.18 to 1.19 to 1.20 to ... 2.0 and Nightly Builds #11587
-
|
Out of interest: how is actually the development of MP steered ? If I understand it right, there are (at least) two main drivers: compatibility of CPython and the fact that MP is typically used icm microcontrollers, device with limited resources. What criteria are used to - for example - decide to stop working on 1.19.1 code and release 1.20 ? And will there be next a 1.21 or is there a 2.0 coming (I see references to a 2.0 made, although I cannot judge if these references were based on any active development "in the background"). Then - pls appreciate I am not a sw developer by background or experience - what is the exact relation between the pull-requests I can view in Github and the Nightly Builds ? Is there a (simple) way to correlate a resolved issue and a specific nighlty build. Reason for asking is also to determine if / when it makes sense to upgrade the pile of Rp2040's I have for various projects. When 1.20 was released, it came with a long list of improvements, changes listed which I gues is the accumulation of all mods implemented since 1.19.1. Having raised all these questions, pls accept my huge appreciation for all the work done by all the - I guess - predominantly volunteers giving us new features, very stable sw AND taking again and again time to educate the likes of myself with questions we have and the advice we seek. Great work ! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Yep, that's a big part of it. In more detail:
A few releases ago we decided to move to a regular (2 monthly) release cycle. Unfortunately a few hiccups have gotten in the way of that, which is why there was such a long delay from 1.19 to 1.20. (For example, we really wanted to get Pico W BLE support into 1.20, but circumstances out of our control prevented that. In hindsight we should have just shipped 1.20 earlier and done Pico W BLE in 1.21...which is how it's going to work out anyway!). We're back onto the two-monthly plan, so 1.21 is targeted for approx end of June. It's going to be a much smaller release than v1.20 :) There will be a 2.0 at some stage soon. We do our best to maintain backwards compatibility between releases -- most code written against even the very early releases will still work today on the latest version. However there are a number of "features" in MicroPython (many of which trace back to decisions made almost 10 years ago) that need to be revisited in order to move forward with improving the developer experience, but unfortunately this will mean a small amount of backwards compatibility breaking. So I think 2.0 will likely be that opportunity -- a once-off point to remove some things and change some other things. The 0.0.1 releases (e.g. 1.19 -> 1.19.1) are just when we need to do critical bug fixes. We've decided to always add the .0 to the name, so you'll notice that v1.20.0 is the name of the 1.20 release, where it was just v1.18 for 1.18).
If a pull request is marked as merged, or as closed with a note saying it was merged, then within ~24 hours that code will be in the nightly build. If the pull request is marked as "open", or closed without a note from Damien saying it was merged, then it will not be in the nightly build. The nightly build firmware filename includes the git hash they were built at, so you can manually verify what they include by looking at the git history. Unfortunately there's no way in GitHub to mark a PR as "merged" unless the author's changes were merged exactly. But often we make small fixes or need to rebase during the merge, so instead we have to mark them as closed (with a note saying it was merged). Where possible we've started trying to do things like push changes back to the author's branch so that GitHub does the right thing. When we publish a release, the full list of changes (both as a summary and also as a list of commits) is published at https://github.com/micropython/micropython/releases The rp2040 did get some useful improvements in v1.20. We work hard to ensure that 1.x releases don't break things or introduce performance regressions, so in general it should always be safe to upgrade. It also makes it easier for us to provide help if you run into issues if you are using the latest version. The only exception to compatibility is if you're using .mpy files, we periodically change the bytecode format, so you just have to re-compile your .mpy files with the corresponding version of mpy-cross. This happened from v1.18 to v1.19 for example. (If you don't know what that means, don't worry). |
Beta Was this translation helpful? Give feedback.
-
|
Just to avoid anyone worrying too much about backwards compatibility breaks, mostly the stuff I'm talking about is where different ports have implemented things differently (and incompatibly), and we need to unify them. But you have to break one of them to make them the same. A few areas in the |
Beta Was this translation helpful? Give feedback.
-
|
thank you very much for your clarifying response. (And no, not worried about .mpy as yet. Still plenty of other things to look into before I move into that area). |
Beta Was this translation helpful? Give feedback.
Yep, that's a big part of it. In more detail:
Compatibility with CPython -- the language is evolving, and while we can't support every feature we do need to ensure that "common" Python code works as people expect. Initially MicroPython supported Python 3.4, but since then many features have been added to Python that we now expect to see in regular use in Python code, such as f-strings, async/await, bytes.hex(), etc. So we add them to MicroPyt…