[Releasing] Changelog for 5.0 (Was: Content freeze for Qt 4.8.3 approaching)

[Kent Hansen]

Hi Akseli,

Den 03. aug. 2012 15:10, skrev ext Salovaara Akseli:
>
> Hi all,
>
> It has been great  to notice that Qt 4.8 branch is active and has 
> already well over 200 commits since Qt 4.8.2 release.
>
> Therefore it is suitable time to start creating Qt 4.8.3 release, as 
> discussed earlier.
>
> We would like to freeze Qt 4.8.3 sha1 in mid-August aiming to have Qt 
> 4.8.3 release ready, tested and published around the end of August.
>
> If you are aware of some improvement or fix which should be included 
> (and/or is possibly pending on review) please send email to 
> releasing at qt-project.org <mailto:releasing at qt-project.org> . Any 
> information from e.g. some fix partially approved is valuable and very 
> welcome. As has been discussed before, we are making the 4.8 patch 
> release directly from 4.8 branch. So we will not cherry pick anything, 
> getting something in means that we take all commits in by that point 
> in time.
>
> There are a few contributions pending to be merged to 4.8 in Gerrit 
> (link: 
> http://codereview.qt-project.org/#q,project:qt/qt+status:open,n,z). It 
> would be great if all maintainers  who have not yet done so go through 
> these for their modules and all  contributors who have received 
> comments try to fix the things needed to be accepted.
>
> Qt version bump up and dist/changes-4.8.3 update are under work but 
> you can find working draft of changes-4.8.3 file as attachment.
>
>

Nice work on the changes files (for the previous patch releases, too)!

On that topic: How should we proceed in preparing the changes file for 
5.0? Should there _be_ a unified changes file for 5.0? (I noticed that 
there's no changes-4.0.0 file; guessing that's because the leap from Qt 
3 to 4 was so huge (e.g., in terms of source-incompatible changes) that 
an incremental change documentation didn't make sense.  Can we use the 
same excuse for Qt 5? :-/ )

In the olden days, it used to be the responsibility of each developer to 
add his contributions to the changes file when a release was drawing 
near. Admittedly, this was not everyone's favorite activity, having to 
dig through your own ~half year old commits. Some steps were taken to 
ease the process (I think it was Harald who wrote a nifty tool that 
would find all your commits and let you strike them off the list as you 
went and added changelog entries), but there was still a fair amount of 
release manager nagging and developers' moaning before it got done. [1]

On the other hand, in order for someone other than the developer that 
did the change to create the changelog entry, the bug 
summary/description and/or commit message need to be of pretty high 
("user-centric") quality (which I'm sure is the case in many, but 
perhaps not all, cases). It's probably manageable (as you've shown) for 
the types of changes going into 4.8, but 5.0 is a different beast.

So my question is: Should I wait for Some Magic Guy (Lars, is that you?! 
;D ) to make the 5.0 changes file materialize in pristine form by next 
month, or should each developer, or at least module maintainers, get 
involved somehow? How will it be handled for subsequent minor and patch 
releases? With Qt now being an open project, certainly the release 
manager can no longer play the "It comes with the job, now write the 
changelog dammit!"-card to all contributors.

Lastly, I'll note that having the changes-5.0.0 file in qtbase seems 
strange; is that file supposed to include changes to other modules, such 
as qtdeclarative, as well? Would qt5.git be a better place for it? 
Should each module have its own changes file that some script combines 
into a final one?

Best regards,
Kent

[1] Yes, there were discussions on switching to a WebKit-style 
"every-change-should-have-a-changelog-entry", as a way of ensuring that 
all changes got documented, at a time when the developer was still 
around and even recalled what he had done. There are pros and cons of 
each approach [2]; WebKit's changelog is not a "release" changelog like 
Qt's is, so the process is not immediately applicable.
[2] *must resist further bikeshedding urges*