Lots of positives from my first try with OS 2.0.0-RC.4:
+++ WiFi (on Photon) now seems to behave correctly in all the scenarios tested so far
Not a very scientific evaluation - wondering what others have found?
Some example warnings? What seems legit often depends on subjective interpretation 
I was rushing to post - here are the warnings from the compile - nextTime is declared as char nextTime[6];
-base.ino:19276:46: warning: '%02i' directive output may be truncated writing between 2 and 11 bytes into a region of size 6 [-Wformat-truncation=]
19276 | snprintf(nextTime, sizeof(nextTime), "%02i:%02i", _hr, _min);
-base.ino:19276:46: note: directive argument in the range [-1073741839, 1073741843]
-base.ino:19276:46: note: directive argument in the range [-30, 30]
-base.ino:19276:17: note: 'snprintf' output between 6 and 16 bytes into a destination of size 6
19276 | snprintf(nextTime, sizeof(nextTime), "%02i:%02i", _hr, _min);
Always welcome your insight on these matters.
I can add that I have now seen the memory usage for 2.0.0-RC.4 is slightly less than 1.4.4 - so that is another +ve.
These warnings are legit since the compiler doesnāt know that your _hr and _min will only ever be 0ā¦23 and 0ā¦59 respectively. It will go with the full range of the given data type and hence must assume you may end up losing āvaluableā information when at least one of the values would require more than two digits.
Warnings are meant to flag potentially problematic regions for the programmer to make reconsider or just accept the warning.
IIRC, if one once to be very āpedanticā and get rid of all warnings you may even be able to tell the compiler to not flag this for a specific instruction since you know itāll be fine.
But donāt ask me how itās done with this version of GCC
So there is nothing really I can do to silence these warnings - which are correct but āover protectiveā?
As I said, there are possibilities
This might work (or not - 
)
Having tried a few other apps I can see the warning āfine combā is going to be a feature!
I thought there might have been more feedback on experience with this OS??
@mstanley thanks for help on support ticket about an odd WiFi behaviour problem since OS after 0.8.0 - 2.0.0-rc.4 appears to have cured it, increased App Flash usage accepted if that is the cost.
Hey Will. I wanted to follow up on this thread to make a final note to close the loop.
Decreased flash space is going to be a consequence of upgrading to 2.0.0. from 1.4.4. Particle is looking to commit to a minimum flash space and RAM allocation in future releases. Thereās no specific commitments I can call out at this time, but this is something we want to commit to to add a level of reassurance in future releases.
Thanks for following up. I have found a few issues since - they relate to the classic System.sleep() API which wasnāt working. I then migrated to Sleep2.0 and then found that the following doesnāt work:
ULTRA_LOW_POWER
SystemSleepWakeupReason wakeupReason() const;
SystemSleepResult result = System.sleep(config);
if (result.wakeupReason() == SystemSleepWakeupReason::BY_GPIO)
I am using WKP pin to wake because I need to wake from HIBERNATE on this rising.
I have therefore reverted to reading the WKP state instead.
Also, I need to test for the WKP pin being LOW and stable before calling System.sleep() otherwise it does not go to sleep correctly.
Just wondering whether a quick migration guide might be useful?
Hey Will!
Unless Iām mistaken, I believe youāve already filed reports for these, correct? Engineering is handling these reports internally and I believe will be following up with your bug report source once deliverables or follow-up asks as they are available.