MicroPython Forum (Archive)

Hello,

I now there are some differences between 1.9.x version and olders (see the "On-Off-Gate" for example).

I would like to know how to deal with these differences. For example I have this code :
that doesn't work anymore on 1.9.2.

How to make it work again, with asking you guys every time a new error occurs ?

Thank you,

Regards,

Ioukos

Are you sure it ever worked before as intended, and should not read:

Oh, you must be right !

I'm a bit lost with changes that could occur, but not necesseraly.

Thank You very much.

But as a general problem, this is really a big issue. There is basically no place where this would be documented by the developers. Even the changelogs don't mention such incompatible changes.

But as a general problem, this is really a big issue. There is basically no place where this would be documented by the developers. Even the changelogs don't mention such incompatible changes.

Changes appear to be tracked in Releases and collated in the very long micropythonChangelog.txt. (The collated text file is helpful for searching.)

I think there's a lot of detail there. Would this not be where you would expect those kinds of changes to be documented?

They're not perfect of course; the major breaking change of 1.9.1 (Pin high/low->on/off) was not clearly noted, it was left to the details. It ought to have been noted in the summary at the top; I suspect this was an oversight...

Well, to start with, there should be a deprecation warning at least one release in an advance, and then a clear information of what has been deprecated exactly and what should be used in its place.

I have the impression that Paul & Damien do already a lot to document the product and it's changes. many of the issues raise here could be avoided if people look into the documents. I doubt that there is a kind of long run plan about which changes to implement and it's possible inconsistencies over the next n versions. And some of the the changes people complain about were cause by improvements in error handling and language conformance of MicroPython.
So maybe it's better make use of the 1000 eyes of the people, and let us all report on inconsistencies being found at a special section of this forum, allowing all of us to look at a this specific place, if code after a version change has a hiccup.

Roberthh wrote:I have the impression that Paul & Damien do already a lot to document the product and it's changes.

The trick is not to do a lot, but to do little and still cover the important parts.

Roberthh wrote:Many of the issues raise here could be avoided if people look into the documents.

I don't think anybody really had this kind of commitment to a project that doesn't care much for them. It's drinking from a firehose. Unless you are paid to do that for 8h a day, there is no way. I tried it. I lasted about two weeks, and it prevented me from doing pretty much anything else.

Roberthh wrote:I doubt that there is a kind of long run plan about which changes to implement and it's possible inconsistencies over the next n versions. And some of the the changes people complain about were cause by improvements in error handling and language conformance of MicroPython.

Yes, this is a big part of the whole problem. There is no plan. There is even no policy. It's all up to the last-minute whims of the developers. Like that, MicroPython will never be stable enough to use it without making your own fork and hiring people to maintain it.

Roberthh wrote:So maybe it's better make use of the 1000 eyes of the people, and let us all report on inconsistencies being found at a special section of this forum, allowing all of us to look at a this specific place, if code after a version change has a hiccup.

That's not possible. This kind of task can't be split into 1000 eyes, each doing a small part, because it's about spotting missing things, not finding something that is there. So you really need one person that reads *everything* and remembers it and can see the problems. Or, alternatively, you can introduce a policy for the developers to document what they change when they change it (or even better, when they plan to change it) in a way that is accessible for the users. And copy-pasting a list of commit messages into the changelog is not going to do that.