ESP8266 Developer Zone

Re: feedback on sdk versioning and patches

2015-07-20T17:06:28+08:00

Hi,

Thanks for your advice !

We will optimize it !

Statistics: Posted by ESP_Faye — Mon Jul 20, 2015 5:06 pm

Re: feedback on sdk versioning and patches

2015-07-19T22:57:49+08:00

Plus I have seen people applying 1.1.2 patches to the 1.2.0 SDK. Needless to say that the project did not compile.

Statistics: Posted by blubb — Sun Jul 19, 2015 10:57 pm

Re: feedback on sdk versioning and patches

2015-07-19T22:55:49+08:00

That would indeed be very useful. You could call these versions 1.2.0.1/2/3 or 1.2.0a/b/c. At the moment it is sometimes unnecessary complicated to find out what lib file is the most recent if it is present in several zips.

Statistics: Posted by blubb — Sun Jul 19, 2015 10:55 pm

feedback on sdk versioning and patches

2015-07-18T20:45:00+08:00

@espressif: thanks for keeping up the development of esp8266 sdks - without this, esp8266 could not be picking up the community support it deserves

On the topic of Espressif's SDK (non-rtos) versioning, when there are patches on top of some version, this should produce a minor or revision version increment..

e.g.,
for ESP8266 SDK（esp_iot_sdk_v1.2.0_15_07_03）
there have been 3 patches:
SDRAM Optimization Patch for SDK_v1.2.0
Patch for SSL based on SDK_v1.2.0
Patch for SmartConfig based on SDK_v1.2.0

With these patches, I would expect a single SDK download of a 1.2.1, (or assuming 3 separate patches, version 1.2.3), which include 1.2.0 plus patches, rolled up.

Having separate patches to apply on top of some sdk makes it trickier to implement projects on top of SDK, as well as can cause confusion when community is discussing issues around a particular sdk version. E.g., "Dev A: I had problem X with SDK version Y. Dev B: Did you have patches 1, 2, and 3, applied?"

Please consider rolling the patches into a monolithic SDK revision. This would help disambiguate any differences in releases.

Statistics: Posted by zerog2k — Sat Jul 18, 2015 8:45 pm