Versions > 1.9.0

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
User avatar
ioukos
Posts: 34
Joined: Wed Oct 19, 2016 11:31 am
Location: Alsace, Europe

Versions > 1.9.0

Post by ioukos » Sun Sep 03, 2017 9:50 am

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 :

Code: Select all

	elapsed = utime.ticks_ms / 4000
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

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Versions > 1.9.0

Post by Roberthh » Sun Sep 03, 2017 12:05 pm

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

Code: Select all

elapsed = utime.ticks_ms() / 4000

User avatar
ioukos
Posts: 34
Joined: Wed Oct 19, 2016 11:31 am
Location: Alsace, Europe

Re: Versions > 1.9.0

Post by ioukos » Sun Sep 03, 2017 3:46 pm

Oh, you must be right !

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

Thank You very much.

User avatar
deshipu
Posts: 1388
Joined: Thu May 28, 2015 5:54 pm

Re: Versions > 1.9.0

Post by deshipu » Sun Sep 03, 2017 8:26 pm

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.

User avatar
mattyt
Posts: 410
Joined: Mon Jan 23, 2017 6:39 am

Re: Versions > 1.9.0

Post by mattyt » Mon Sep 04, 2017 12:41 am

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...

User avatar
deshipu
Posts: 1388
Joined: Thu May 28, 2015 5:54 pm

Re: Versions > 1.9.0

Post by deshipu » Mon Sep 04, 2017 7:46 am

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.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Versions > 1.9.0

Post by Roberthh » Mon Sep 04, 2017 7:57 am

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.

User avatar
deshipu
Posts: 1388
Joined: Thu May 28, 2015 5:54 pm

Re: Versions > 1.9.0

Post by deshipu » Mon Sep 04, 2017 10:36 am

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.

Post Reply