apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r822263 - /apr/apr-util/branches/1.4.x/CHANGES
Date Tue, 06 Oct 2009 14:16:29 GMT
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.)

Mime
View raw message