0.15.0-rc1

[netmindz]

No description provided.

[willmmiles]

I recommend prioritizing a fix for #4260 before moving to RC, especially since it pertains to version identity data.

[netmindz]

Thank you @willmmiles for bringing #4260 to my attention, yes that will need to be fixed before the Release Candidate

[blazoncek]

IMO #4260 was a build glitch. IDK how it happened (it shouldn't).
The easiest way to check is build, upload and verify.

[blazoncek]

If there are any commits or PRs merged add them to change log.

[blazoncek]

When making a release, update with all PRs and commits that happened after b7.

[netmindz]

Done

[softhack007]

I'm seeing a few new bug reports related to the LEDs setting UI. Maybe we should analyze them before going to RC.

• Disabling brightness limiter requires additional changes before saving #4277
• Various usability problems in the LEDs settings page - Type not changeable, GPIO, Length and mA/LED settings sometimes lost upon save #4280
• (fixed) Crashes when leds length is 3 #4120

Plus this one that seems to affect all S2 users

• OTA Updating ESP32-S2 from 0.15.0-b4 fails - if Tasmota Web installer was used #4241

[blazoncek]

Disabling brightness limiter requires additional changes before saving #4277

I could not reproduce. Perhaps requesting browser logs is in order.

Ports >3 lose GPIO, Length and mA/LED settings upon save #4280

May be related to limiter. I could not reproduce. Same submitter as previous. Perhaps issue on his/her setup.

Crashes when leds length is 3 #4120

This one should be easy for anyone to reproduce if true. I could not.

OTA Updating ESP32-S2 from 0.15.0-b4 fails #4241

I have 3 S2 units in production use (>400 pixels, multirelay, PIR sensor, temprature usermods, MQTT), all updated OTA regularly with no issues. Same with @DedeHai . @willmmiles did see issues though. Probably device FS issue.

I am sure that in all cases debug log and crash dumps with exception decoder are needed to diagnose. None were provided since submitting.

[k7bbr]

Disabling brightness limiter requires additional changes before saving #4277 <#4277> I could not reproduce. Perhaps requesting browser logs is in order. Ports >3 lose GPIO, Length and mA/LED settings upon save #4280 <#4280> May be related to limiter. I could not reproduce. Same submitter as previous. Perhaps issue on his/her setup.

I easily reproduced this issue when flashing a new, out-of-the box WT32. Unable to set pins or pixel type. The module was completely bricked for 0.15.x even after USB flashing to 0.14.4 and the flashing again to 0.15.x. not just a single user.

…

Crashes when leds length is 3 #4120 <#4120> This one should be easy for anyone to reproduce if true. I could not. OTA Updating ESP32-S2 from 0.15.0-b4 fails #4241 <#4241> I have 3 S2 units in production use (>400 pixels, multirelay, PIR sensor, temprature usermods, MQTT), all updated OTA regularly with no issues. Same with @DedeHai <https://github.com/DedeHai> . @willmmiles <https://github.com/willmmiles> did see issues though. Probably device FS issue. I am sure that in all cases debug log and crash dumps with exception decoder are needed to diagnose. None were provided since submitting. — Reply to this email directly, view it on GitHub <#4287 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGGPSXCZAGYGMPMTVADGIXL2A6KDNAVCNFSM6AAAAABR37JB7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQG42DCNJVHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[willmmiles]

Re #4277 and #4280: I've seen something in this vein (LED settings not saving) on my test setup. I was having a bunch of unrelated connectivity issues, so I just wrote it off at the time. Trying to reproduce it now.

Re #4241: I'm 95% confident that what's happening is heap starvation of some kind. S2s have practically as little RAM as 8266es, but all the code (including the platform!) treats them like the bigger ESP32s. I could also reliably trigger a heap exhaustion crash by messing up the upload parameters so it didn't get handed to Uploader properly. I'm going to probe to see if there's something I can do in AsyncWebServer to trap that case and not crash, at least. (Doesn't answer why ArduinoOTA and other non-webserver uploads also fail for some users, though.)

[netmindz]

Ok, it wasn't my original intention with this PR, but are we ok with adopting this as the issue where we track items that must be resolved before the RC?

[blazoncek]

@k7bbr please provide crash dumps or debug logs in respective issues, not here.

@willmmiles try ArduinoOTA for S2. Uses different route.

[softhack007]

I've just linked / referenced some bug reports where i feel we should understand what's going on, before going forward to release RC1.
It seems to me that bugs are "clustered" around

• Problems with the LEDs settings page
• Unexplained crashes related to mixing output types: DMX-out; mixing RGBW and RGB leds
• Segment-related usability problems (possibly non-blocking if we understand them better)
• OTA update on S2

[blazoncek]

@softhack007 I do agree with releasing as thoroughly tested code as possible but if you look in the past, b5 was officially released at the beginning of September and there was really sparse feedback on it (or prior to that, b6 and b7 included minor changes and received same amount of feedback).

IMO if you want to get enough feedback, release 0.15.0, gather feedback from real use and provide 0.15.1 ASAP based on the feedback. Otherwise you'll be stuck in release limbo in which WLED is for far too long already IMO.

No software, in all my 40+ years of experience, is released bugfree. Ever.

[softhack007]

IMO if you want to get enough feedback, release 0.15.0, gather feedback from real use and provide 0.15.1 ASAP based on the feedback. Otherwise you'll be stuck in release limbo in which WLED is for far too long already IMO.

No software, in all my 40+ years of experience, is released bugfree. Ever.

@blazoncek I think we already have enough feedback to fix issue before "pushing the thing out". I agree with you that no software is bug-free. However from my also 35+ years in software, and 20 years of this in software quality, I know that two things are very important if you don't want to lose trust of users:

• no regressions - what worked before should still work after installing a new release. Unless there are clear warnings in release notes.
• good first experience - so features like settings up LEDs or managing segments should not get you stuck (cannot save) or lead to crashes of loss of settings.

After that comes the "wow" about new stuff that comes in a new release. And yes, users will forgive errors and "glitches" in newly added features. But on the other side, they may regret installing an update, if it means they cannot continue working on the Christmas Lights because missing a usb cable to flash the old software...

Just my "words of reason" - every maintainer should have an opinion and finally we will all decide together when to release. It doesn't mean what I'm saying is the only truth in the world 🤷

[netmindz]

Fix for #4260 ready for review

[blazoncek]

Just a reminder:
There are 90 PRs open waiting to be merged (either for 0.15.1 or 0.16) and we are debating if we add quotes or not to WLED_RELEASE_NAME while the simplest solution is on hand.

And then there's this:

Long overdue now.

Has anyone tried to reproduce issues @softhack007 pointed out? I was not able to do so.

#4260 just needs a replacement of ESP8266 and ESP32 to something not recursively expanding (see my suggestion and reasoning above and the following screenshot)

#4120 has been resolved by @willmmiles
#4241 has been most likely caused by Tasmota partition map (three of us were unable to reproduce)
what about #4277 & #4280? @netmindz pointed out (and my own observation) that that particular user opened a few issues, all at once, with no detailed feedback when requested

I am sorry if I sound and behave like a big PITA but time is so short now that if we do not release 0.15 before December it may be pointless to release it as-is and better go on developing and merging PRs.

[softhack007]

I am sorry if I sound and behave like a big PITA but time is so short now that if we do not release 0.15 before December it may be pointless to release it as-is and better go on developing and merging PRs.

Ahem... yes ... as you say ... you sound like a manager who knows nothing but schedule.

It's good that some of the issues I pointed out are now clarified, and for sure we can decide to address some points later.

I'm not sure what you want to say by quoting AC - so we should simply release because @Aircoookie would love to see a release in November (and his statement is from September) ? C'mon give me a break - or are you just joking?

[netmindz]

There is a LOT we need to do with regard to PR management and the actual release process, it's way too fragmented and labour-intensive as it stands, but we just need to get 0.15.0 out, get the new process and CI in place.

I've just updated the RC1 with what we have merged so far we still have a few open issues we need to decide one way or the other with.

A few items were labelled as being for the final release we haven't discussed and a few we haven't, some can perhaps wait for the GA release of 0.15.0

https://github.com/Aircoookie/WLED/milestone/12

[blazoncek]

#4300 fixed and waiting in PR