On Tue, Oct 6, 2009 at 9:58 AM, Graham Leggett <minfrin@sharp.fm> wrote:
trawick@apache.org wrote:

> URL: http://svn.apache.org/viewvc?rev=822263&view=rev
> Log:
> Remove entries for iterative fixes to the crypto feature since
> it has not yet been in a release.
> Remove entry for a change to the apu_dso_load() interface since
> it is a private function.

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.)