> -----Original Message----- > From: Development <development-boun...@qt-project.org> On Behalf Of > Shawn Rutledge > Sent: Tuesday, 2 April 2019 1:46 PM > To: development@qt-project.org > Subject: Re: [Development] Switching from create_changelog.pl to > createchangelog for change log generation > > > > On 2 Apr 2019, at 11:40, Mitch Curtis <mitch.cur...@qt.io> wrote: > > ... > > So, the end result of switching to this is that it becomes clearer that we > > are > actually fixing (non-trivial) bugs, contrary to what the "only minor code > improvements" message says. Yes, it does mean that you will have to edit > more stuff, but it's mostly just removing commit message bodies, which are > included (if I understand correctly) in order to give more context than would > otherwise be available had it just included the commit summary. > > > > If no one has any serious objections, I'd like for us to start using this to > create the draft change file commits as soon as possible. > > > > [1] > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/create_ch > > angelog.pl [2] > > https://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog > > <qtquickcontrols2-5.12.3.txt><qtquickcontrols2- > dev.txt>_______________ > > ________________________________ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > Yeah thanks to Simon for starting that and for writing it in go. ;-) > > I added that feature to get all the bugs as well as the changelog entries: if > a > Fixes or Task-number is found, it queries Jira for the bug subject line, and > also includes the descriptive part of the commit message. The result is > verbose, but I prefer condensing it down rather than having to open up bugs > individually in a browser whenever the commit message doesn’t tell the > whole story. Of course I also remove non-user-facing entries like doc fixes, > fixes to really short-term regressions that didn’t get into a release, deep > internal stuff etc. And I have to reorganize them because the tool doesn’t > detect which fixes are to QtQuick and which are to QtQML for example (let > alone any finer-grained categories), although it could maybe be enhanced by > looking at which files got changed.
Thanks! > I found one more issue though when I was re-generating the 5.9.8 > changelog: it got confused that there were tags on newer branches. I had to > delete all the 5.12.x, 5.11.x and 5.10.x tags from my local checkout so that > it > would see that 5.9.8 is the newest. But I’m sure that can be fixed. > > After that, we could indeed try using it for the mass changelog generation, as > long as the other maintainers are OK with the verbosity that it generates. Hmm, OK, so it's not quite ready to be used yet. > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development