Jeff Trawick wrote: > My understanding: Each of these deleted entries thus far is a minor > implementation detail related to the new apr_crypto feature. As the > feature was never released, they do not fix a problem for the users of > our library. OTOH, any of these if tied to a particular user symptom > could be interesting in the change log for a bug fix release, such as > 1.4.1.
Now that I have some time to draft a proper reply. The argument that "the feature was never released" becomes moot the moment the code is released, and that will happen when we ship APR v1.4.0 (or APR v2.0.0). At that point, end users are going to want to know what's changed between the last release and this one. And in the case of APR v2.0.0, people are *really* going to want to know what has changed. More specifically, people are going to want to know exactly how that change got there, and that feature morphed over time to become what it is now. What you're arguing for is a "dumbed down" version of CHANGES, where only a general announcement of a feature is included, but the core details of how the feature got there are erased. And I'm firmly opposed to that. CHANGES isn't a marketing brochure, it's the thing that will show up in google searches when end users are trying to debug a problem. And we can fully expect problems to found when APR v2.0.0 is released, and people to want to fix them. There is a further, deeper reason why I oppose these changes to CHANGES - the changes documented were committed 18 months ago. Without having recent memory to go by, we are arbitrarily chopping out sections of our history based in whether an entry looks "important" or not. We are changing our historical record, and that is a really bad idea. We have no idea what information might be vital to an end user to solve a particular problem they have. An innocuous looking change could be the cause of a bug. And no, end users of the library aren't going to be checking out apr from svn to try and find the history. We certainly should not be making end user's lives more difficult for the sake of saving a few bytes. On this basis, my -1 stands. Please revert the CHANGES (so to speak). Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
