totally agree with @Eric Pai and @gaoyang. Dependabot can be only as a notification, and we need to check whether we can upgrade one by one (or in batch)..
Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 gaoyang <[email protected]> 于2021年10月19日周二 下午3:08写道： > > +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. > >
