Since http://lists.qt-project.org/pipermail/development/2016-October/027542.html , Coin tests all changes against Qt5 instead of the latest version of all modules.
The situation is sth like, some new APIs were added to qtbase in 5.10, and other modules were adapted. But around beta or sometime(before release), some refactoring work happened on those APIs. We adjusted them in qtbase, and other modules. We have several steps to make sure those thing to be approved in CI/COIN. But the order of things gets lost easily when merging the changes up, for example to the dev branch. Here are some suggestions to make those steps more clearer to the people who maintain merge and integration. The changes that are important to be merged up before other changes should have a special tag, such as API_CHANGE in the commit message. Then the script used to do the merges could stop and/or warn about commits with this tag in the message, which would make the merge easier. We can also apply this check into the submodule update script. The situation is also valid for some private API changes(which were used cross qt submodules). About which labels are better to be used for this purpose, please give your suggestion and votes. Thanks. Best Regards, Liang _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
