How is the MP release policy defined ? #18383
Replies: 2 comments 1 reply
-
|
Hi @Flipje1955 and thank you for the interest. MicroPython has a very small team of core maintainers. We in the development community try to offload them as much as possible, by doing issue triaging et.c. But as a large and heavily used project, there is indeed a large backlog (including some things quite old). There not much formal description (that I am aware of) for the prioritization of PRs/issues. There are multiple tiers for hardware/ports, as described in https://docs.micropython.org/en/latest/develop/support_tiers.html - so lower tiers are likely to get lower priority. A pull request generally gets merged to master when it is approved. And the release process itself is basically to tag master, after doing extensive on-hardware tests to check for regressions. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your quick response. Realizing to interact with - I would assume - an enormous user-base (you may have any numbers), I can understand for a small team to engage in "hey, buddy, what would you like to see incorporated in a next release" is way too much of an ask. However, the way you describe the process followed to establish what is in a next release, feels like "the other side of the spectrum". Don't get me wrong, I really enjoy (and benefit from ) the energy and enthousiasm by the team and all the contributers around it. And at the same time, you may appreciate that for somebody OUTSIDE the team you describe, there is no hint what is coming, when / if_at_all "unfinished business" might be completed (I2S: ... "The I2S class is currently available as a Technical Preview....", Threading: "This module is highly experimental and its API is not ....") is expected to be addressed. These statements are in the docs since quite some time; will there be any follow-up soon ? Who knows. Can the priorities be influenced; it appears they cannot. I guess after having stated the above, it will not come as a surprise that I encourage the MP community to not only (rightfully) enthusiastically report what has been added in the new release, and ALSO - does not need to be at the same moment in time - give an outline what priorities have been set for the next development cycle(s). I realize there may be many unknowns at day-one, I would be surprised one cannot define a set of must-haves or key developments targeted; if so, why not publish it (and thereby also strenghten the ties with your user-base). nb. Wrt you reference to commercial work: I may rightfully state I understand what that can do with planning and priorities. I have an almost 40 year experience in the distibution and support of professional ERP software (SAP etc) for an internation client base. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Pleased to see that new functionality is added, issues are fixed. It appears a new version is released every say 4 months. Thank you to all involved to keep this process going !
I am interested to understand how it is decided to included what in an upcoming release. To some extend this can be seen by looking at the Github Milestones (ie now for 1.27) and it appears as the functionality is a mix of recent changes and changes initiated as far back as 2022. Does this imply there is a backlog going back several years ?
The count of pull requests submitted since the current release exceeds the count shown in the release milestone. A(n approved) pull request is no guarantee that it will find its way to the next (upcoming) release ?
Related, I saw references being made to a version 2. What would be major developments that would drive a major update ?
The above is just curiosity into what goes into the work done to manage the lifecycle of MP. Thx for any insights in the 'behind the scenes'.
Beta Was this translation helpful? Give feedback.
All reactions