On Tue, Oct 6, 2009 at 9:58 AM, Graham Leggett <email@example.com>
Can someone explain (and document) the new thinking behind how CHANGES
is supposed to work?
Generally: If it isn't useful info to library users, it doesn't go in CHANGES. We track CHANGES based on releases, not based on Subversion commits, so a further refinement is that entries should be useful info for library users who download a release from us, not for those who svn up every few days.
If before a new feature is delivered the first time it has to be patched n times (like many new features do), the only entry needed in CHANGES is the one that announces the feature. Once the feature has actually been in a release, CHANGES entries for following releases should show how it was fixed.
If some internal detail is changed (like a change to the private apu_dso_load function), it doesn't go in CHANGES.
I don't see anything new about this philosophy. (That's not to say that the philosophy has been followed faithfully until now. It just seemed obvious to me that this particular CHANGES should be cleaned up on behalf of folks wondering why there is going to be an APR-util 1.4.0 release.)