[Releasing] Changelog for 5.0 (Was: Content freeze for Qt 4.8.3 approaching)
kent.hansen at nokia.com
Fri Aug 10 08:54:46 CEST 2012
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
> 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. 
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?
 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 ; WebKit's changelog is not a "release" changelog like
Qt's is, so the process is not immediately applicable.
 *must resist further bikeshedding urges*
More information about the Releasing