I'm migrating code from arduino-esp32 core v1.0.6 to core v2.0.3.

Part of what broke is this bit of (highly simplified) code:

WiFiClient stClient;
IPAddress stIP;
uint16_t stPort;
if ( stClient.connect(stIP, stPort, 100) ) { // try to connect to the server, waiting up to 100 ms
 // do things...
}

The above connects 100% of the time under 1.0.6. but under 2.0.3 it fails 100%.

Using v2.0.3, I could only get it to connect if I left out the timeout parameter, as in:

if ( stClient.connect(stIP, stPort ) ) { // try to connect to the server, waiting up to 100 ms
 // do things...
}

or if I set the timeout parameter value to at least 1000 as in:

if ( stClient.connect(stIP, stPort, 1000) ) { // try to connect to the server, waiting up to 100 ms
 // do things...
}

So I compared the WiFClient.h and WiFiClient.cpp files from core versions 1.0.6 and 2.0.3.

Of the changes to the v2.0.3 .cpp file, a number have to do with the way the timeout or _timeout parameter is used, which make it not backward compatible with the core v1.0.6 implementation.

It seems that in v2.0.3 timeout is now a value of seconds instead of ms (but why do we need a uint32_t value for that??). Internal to WiFiClient.cpp a default timeout of 3000ms is used? Why the breaking change in the timeout parameter in the call to .connect? Or am I missing something?

If everything has to be in seconds (though why??) under 2.0.3 shouldn't any value of timeout less than 1000 throw an error during compile? Or at least a warning? Or use a run-time logw in the .cpp?

Regardless, is there a summary somewhere, relative to core 1.0.6, of the way timeout (for all WiFiClient methods) is used in core 2.0.3?

And an opportunity for improvement -- do the release notes for new core releases track breaking changes? Would be nice (and save hours of debugging) if they did 😄.

Philosophically related to #6835?