Development freeze for Sming Release V2.0

[hreintke]

I propose to enter "Development Freeze" to be able to release next stable version of Sming. As you see in the title, I suggest to use V2.0, in order to distinguish between Sming and SDK release numbering.

I created a Draft release V2.0, please add any necessary lines to the description in order to document the updates/necessary changes for Sming users.

Please comment also with activities still needed before releasing.

[hreintke]

@raburton : What is your opinion on #451 and/or the solution for the esptool issue we have/had.

I'v also seen your "issue discussion" on the esptool forum. Do we need to update compiler options to solve this ?

[flexiti]

@hreintke what about waiting pull requests #442 and #371 ? in my opinion they are save (in the last one is also new metod to chcek WiFi signal strength)

[raburton]

@hreintke I haven't had chance to supply more files to other issue, but I suspect we can fix that issue rather than using the current workaround. This would be preferable because the workaround adds an additional dependency (esptool2) for those users who are not using rBoot.

[raburton]

btw, I've tried to tag issues/prs that have gone into this release, so hopefully it will be easier to see what's in this version. This list won't be complete because I think I'm the only one that's been doing it, but something to try going forward. You might want to rename the milestone 2.0 if that's what we are going for. https://github.com/SmingHub/Sming/issues?q=milestone%3A1.5 https://github.com/SmingHub/Sming/pulls?q=milestone%3A1.5

[hreintke]

@raburton : I do agree on preferable not having the workaround in. I merged that one into develop to keep testing/using of develop branch going.Users of develop (should) know that solution might change before releasing. Do you expect to solve the issue on short notice or do we have to delay the freeze until fixed ?

[hreintke]

@raburton : I had seen once a note on a issue/PR with milestone but didn't know you already used it that much. It's not that visible as Labels. I found the way to rename the milestone and presume and expect that milestone assignments will stay when renamed. Is that correct. I will update other issue/PR that I see and are included in V2.0 with this milestone too.

We then use milestones to identify issue actually solved in and PR's included in the Vx release, not the one that are scheduled to be included in the release. Correct ?

[raburton]

Yes, they stay when renamed. I've now done that. There isn't a big difference between tags and labels really. The nice thing about milestones is you get a progress bar indicating how close you are to completion, so if used correctly you can see when everything is done and you are therefore ready to release. You can also close a milestone so you don't have it in the list for ever once released and can set target dates for them.

[flexiti]

I would like to point out that the current CHERTS programming in windows can download UDK 2.09 (SDK 1.5). It will be difficult for them to find UDK 2.08 SDK 1.4, if they've not downloaded earlier With what UDK and with which SDK this version of sming will work?

[hreintke]

@flexiti : Ok, nice timing from CHERTS :smile: Current version of Sming Develop supports SDK 1.4.0. For that : Windows users need to get UDK 2.0.8 and manually update to SDK 1.4.0.

Not sure yet whether to postpone development freeze to include SDK 1.5.0 support or continue with current and stay at SDK 1.4.0.

Opinions welcome.

@raburton : Entering the Windows world with your rboot in the UDK 2.0.9 examples ?

[alonewolfx2]

@hreintke i think we need to integrate sdk 1.5 firstly. our old release is sdk1.3 and very old. if we freeze on sdk1.4 propably sdk1.6 will release before our next release. @raburton what do you think? @flexiti i will test udk 2.09 tonight. I am using sdk1.5 already but i will deep test if changes full backward compatible i will make PR for sdk 1.5

[flexiti]

I'm for integrate UDK SDK 2.0.9 and SDK 1.5, otherwise we get lost, especially someone who for the first time will want to use sming. I personally will install and will test SDK1.5 this week

[jd4ever]

I agree with @alonewolfx2, especially since it looks like the new 1.5 version supports WPA2 Enterprise now: wifi_station_set_cert_key: set certificate and private key for WPA2 Enterprise

[raburton]

I think it's worth waiting for sdk 1.5 support, one of the big features for this release was 1.4 support, which will look a bit silly now 1.5 is out. The problem is that support for a new version is more about testing than doing, there probably aren't a lot of changes needed to make it work, but after the obvious ones needed to get it to compile any others will take time to find. Also, proper 1.5 support means implementing new features in Sming, like the enterprise wireless support, not just compiling with 1.5, but I guess these can be added later, getting it to compile first is a good starting point.

[alonewolfx2]

@raburton agree. i tested many example of repo and it seems everythings ok with new sdk. we can use sdk1.5

[flexiti]

Develop Sming with the SDK 1.5 and using UDK 2.0.9 (Windows) - it seems to be working properly. The only bad thing is that, with every new version of Sming, the program gets longer, now you can't use the OTA for 512k memory (eg. ESP-01) for even fairly simple program because it is larger than 256 kb.

[tprochazka]

What is bad on keeping the Sming release number the same as currently supported Expressif SDK?

It's bad program is currently bigger 256kB, there should be some way how to skip not used parts of SDK like SSL, AP mode if you don't use it, etc. I'm also looking for OTA update on my project based on 512k model of ESP.

[raburton]

What is bad on keeping the Sming release number the same as currently supported Expressif SDK?

That has already been discussed.

It's bad program is currently bigger 256kB, there should be some way how to skip not used parts of SDK like SSL, AP mode if you don't use it, etc. I'm also looking for OTA update on my project based on 512k model of ESP.

The SDK gets bigger each time and so does Sming. Some options to leave out things you don't want is not a bad idea (please submit a PR), but you have to remember that Espressif recommend devices have a minimum of 1mb flash so it may not be possible to support 512k devices forever.

[hreintke]

@All : Is the Espressif SDK 1.5.0 complete and correct?.

If so, I again propose to take current develop as Smimg Release V2.0

@All : Please update the draft Release info with your knowledge. If we provide decent information we limit the amount of support requests.

[raburton]

I've added a list of features to the release notes based on issues/prs tagged with the 2.0 milestone. Do we want to remove the esptool.py workaround (using esptool2) now that esptool.py has been fixed? Otherwise we need to document that all users will need esptool2 now. I think we should return to the old way for non-rBoot builds and remove this extra dependency.

[hreintke]

I agree to remove additional dependencies. I have no complete/clear view on the esptool.py solution. Is there a new version of esptool which solves the problem ?

[raburton]

Is there a new version of esptool which solves the problem?

Yes: https://github.com/themadinventor/esptool/commit/50459db255b5b32089b80d98d4e32c29cebe4f36 Might be worth a note telling users they should update their esptool.py to the latest version in our release notes.

[hreintke]

I wonder how many windows users have no python installed and only use the the esptool.exe For then it is then the additional dependency for python.

Maybe a dependency of esptool2 is easier to solve ?

[AutomationD]

@hreintke solved here https://github.com/kireevco/esp-alt-sdk

[hreintke]

@raburton : @kireevco @alonewolfx2 @All I just updated/merged

• Sming release number
• Readme
• Release notes To reflect latest state.

@kireevco : Can you update your "download area" to this release ?

@raburton : Can you update the esptoo2/esptool.py documentation and, if needed create and merge the PR for that.

@raburton : Can you merge Develop into Master to deploy Sming Release V2.0.0

[raburton]

@hreintke I don't know what was decided about esptool. I think we should go back to using esptool.py for the non-rboot builds so there is no additional dependency for them (on esptool2). We just need to remind people to update the the latest version. But, as usual, windows users are the problem. If they are using some old version of esptool that can't be updated then maybe esptool2 is the better option.

[hreintke]

@raburton : I think for now the esptool2 option is the preferred.

• Everyone using rboot for OTA has already the dependency
• For compiling esptool2 you need the same devtools as spiffy -> all non-boot spiffs users already have the environment to build.

[raburton]

@hreintke develop has been merged into master and they are now both currently identical. Do you plan to tag it and make the release?

[hreintke]

@raburton : Sorry I completely missed this message. Yes, I will tag and make the release.

Thanks for merging.

[hreintke]

@kireevco : Can you update download areas to point to SDK 1.5.0 ?

[hreintke]

Released