Hi all, Lately it has been quite hard to get change files done for the releases. It should be maintainers responsibility to make sure those will be done for every release and those are containing proper data. We have tried to help maintainers by doing initial ones for them (running script to collect all changes containing [ChangeLog] -tag).
Unfortunately it seems that tag is really rarely used (at least in most of modules) even there is lots of changes in:( In my opinion (almost) all changes in patch level release should be worth of change file entry: If change isn't critical enough for change file entry does it belong in patch level release at all? Could we change our template/sanitybot so that it encourage developers to add change file entries more often and forces them to do it in release branches? One unclear issue related to change files is when we should have one? Should we create one only if there really is some critical changes in the submodule or should we create one in any case? I think the latter one could be more clear one: In first case it is unclear why one is missing? Is it because maintainer hasn't done his job or just because there isn't important changes to be mentioned? In latter case there is that change file for every release and it contains info if there is important changes or not. And another issue is the 'base release' for change files. Someones seems to think change files should contain diff from previous official release (meaning 5.7.1 change files should contain delta from 5.6.2) and others that diff should be from previous release of same series (meaning 5.7.1 change files should contain delta from 5.7.0). I have thought it is latter one and created initial ones based on that assumption. So I propose: 1) Let's enable [ChangeLog] -tag by default in commit template. After that you must remove/comment out it by purpose if you don't want add it. And in addition to this update sanity bot so that it will give '-1' if change log entry isn't given in release branch. This can be bypassed by giving '+1' manually for sanity review if really needed... That way we could get more ready change files directly by running script and so on less work for maintainer. 2) Let's agree every submodule in the release needs to have a change file (to make things clear) 3) Let's agree the change log is the diff between new & previous release in same series (in case of patch level release, meaning delta from x.y.z -> x.y.z+1). And for new major release the diff is from last patch release from previous series Jani Heikkinen Release Manager The Qt Company _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
