+1 To a software engineer, the production environment is holy. Any changes, especially changes from third libs, should have a long tern online procedure, UT, IT, smoking test, function test, regression test, pre-online test, gray test… We have saw too many online cases and accidents related to third part lib’s upgrade. Some of them cannot be rollbacked in time.
For example, several years’ before, we have upgrade the version of spring-data-redis, in which a small serialization signature has been changed. The result is: a large amount of out online data in redis insert by new version cannot be deserialized by old version. And we cannot directly rollback the version to old, because the data in redis has been tainted. Another example: I found the grafana-connector cannot work, details see this JIRA: https://issues.apache.org/jira/browse/IOTDB-1848 <https://issues.apache.org/jira/browse/IOTDB-1848> The cause is related to depedabot, which upgrade spring-boot’s version from 1.5.15 to 2.5.5, whose built-in default database connection pool changed from tomcat to hikaricp, the latter will call setReadonly when creating a connection, the former not. At last, out UT and IT cases are not enough to guarantee the stable of IoTDB。I think we should update the dependency libs conservatively. If not very necessary, should we just stay it as what it was? Any way, stable is the most importance to an online service.
