8000 Roadmap to next release, v1.14 · Issue #6397 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Roadmap to next release, v1.14 #6397

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
dpgeorge opened this issue Sep 3, 2020 · 8 comments
Closed

Roadmap to next release, v1.14 #6397

dpgeorge opened this issue Sep 3, 2020 · 8 comments

Comments

@dpgeorge
Copy link
Member
dpgeorge commented Sep 3, 2020

This is an issue to discuss and plan for the next release. The idea is to aim for a 2 month release cycle, so the next release would be the first week of November 2020. See previous release ticket for v1.13 at #6271

To keep focus and set expectations, a release cycle would have a main goal (eg a set of related new features) which would be the priority. But bug fixes and other items can still be considered.

I know there will be a lot of competing requests for features. There are also a lot of outstanding items. But progress needs to be made and for the next release I propose to focus on:

  • efficient polling with "uevent", and external events in uasyncio
  • non-blocking SSL support in uasyncio

Secondary items to focus on would be:

  • definition and implementation of a common machine.PWM class
  • moving to an Epoch of 1970

Other items still can, and still will, be worked on. But in the interest of having more strict release deadlines there needs to be some primary goals to make the releases meaningful.
@dpgeorge dpgeorge pinned this issue Sep 3, 2020
@tve
Copy link
Contributor
tve commented Sep 3, 2020

FYI, while I like the topics (having worked on 3 of the 4) I will need some scheduling in order to help. I'm pretty busy with projects using MP :-) but have flexibility. What kills me, to be honest, is when it takes a week to get feedback and so I have to reassemble everything from test setup to my memory to make the next round of changes. So if there's a way to coordinate and focus for a couple of days on one issue it would make it a lot easier for me to contribute (which you're free to ignore too).

@dpgeorge
Copy link
Member Author
dpgeorge commented Sep 4, 2020

So if there's a way to coordinate and focus for a couple of days on one issue it would make it a lot easier for me to contribute (which you're free to ignore too).

I understand. Different timezones and remote working can make it hard.

uevent is tough, so I think we should focus on non-blocking SSL first. I will review your PRs on that.

@beyonlo
Copy link
beyonlo commented Sep 4, 2020

@dpgeorge and @tve

  • non-blocking SSL support in uasyncio

I'm working in the application with socket (non-blocking) using uasyncio v3, following exactly the @peterhinch very good examples:
Client: https://github.com/peterhinch/micropython-async/blob/master/v3/as_drivers/client_server/uclient.py
Server: https://github.com/peterhinch/micropython-async/blob/master/v3/as_drivers/client_server/userver.py

That works fine to me, but I would like SSL because I use them over Internet. I'm using ESP32.

Well, that examples above use:

sreader = asyncio.StreamReader(sock)
swriter = asyncio.StreamWriter(sock, {})

Question: with this feature new feature ( non-blocking SSL support in uasyncio), these examples above will works at same way, using asyncio.StreamReader, with SSL?

Thank you so much.

@dpgeorge
Copy link
Member Author

with this feature new feature ( non-blocking SSL support in uasyncio), these examples above will works at same way, using asyncio.StreamReader, with SSL?

Yes, it should work transparently, the socket will act exactly the same whether it is SSL or non-SSL (or any other kind of stream, eg UART).

@t35tB0t
Copy link
t35tB0t commented Oct 29, 2020

Late entries (been away), possibly push to 1.15?

  • Add signal.py cPython still signals (interrupts) support: keyboard SIGQUIT (CTRL-\ ) and maybe SIGTRAP as minimums
  • Add better UDP datagram support to asyncio

@Dr-StephenStrange
Copy link

Would it be possible to get webrepl properly working on the Pyboard D?

At the moment nobody can connect it the main thread is running

@street-grease-coder
Copy link

hope it gets released soon, waiting eagerly, thanks for the hard work

@dpgeorge
Copy link
Member Author
dpgeorge commented Feb 2, 2021

v1.14 was tagged in 78b23c3 on 2nd Feb 2021... a bit later than planned... next release I'll try to be more strict about it.

Above feature requests have been noted.

@dpgeorge dpgeorge closed this as completed Feb 2, 2021
@dpgeorge dpgeorge unpinned this issue Feb 2, 2021
@dpgeorge dpgeorge mentioned this issue Feb 2, 2021
Closed
tannewt pushed a commit to tannewt/circuitpython that referenced this issue Oct 22, 2022
@dhalbert
Merge pull request micropython#6397 from jepler/extra-memset
8825e7f 
Some flash size optimizations related to string0.c (implementation of str/mem functions)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@tve @beyonlo @dpgeorge @street-grease-coder @Dr-StephenStrange @t35tB0t
0