[dev] [cvs] commit: imp/docs CHANGES

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> jan         2008-08-21 09:01:44 EDT
>>>
>>> Modified files:
>>>   docs                 CHANGES
>>> Log:
>>> Add missing entry.
>>>
>>> Revision  Changes    Path
>>> 1.1175    +1 -0      imp/docs/CHANGES
>>>
>>> Chora Links:
>>> http://cvs.horde.org/diff.php/imp/docs/CHANGES?r1=1.1174&r2=1.1175&ty=u
>>
>> Please revert.  This is a rare case where a feature was added to a  
>> release branch but not HEAD.  Address formatting caching is a 4.2.1  
>> change only.  The codebase that will be 5.0 never contained this  
>> change - this branch skipped directly to address parsing caching.   
>> Thus, looking back from a 5.0 perspective, there was never  
>> formatting caching in that branch.  To keep that in there otherwise  
>> is confusing (it makes it look like we are doing both formatting  
>> and parsing caching, which we are not).
>
> I don't agree, though maybe you missed that I added that under the  
> 4.2.1 stanza, in the HEAD branch. It has been added to 4.2.1, no  
> matter in which branch we are.

Sounds like we need a discussion on what the CHANGES file is used for.  
  Obviously, CHANGES is *not* meant to be an all encompassing list of  
what has changed in each release.  We could set up a cvs script that  
would give us this information if this is what we wanted.

Instead, CHANGES lists only the highlights of these changes.  And  
these highlights are presumably there because they make it easy for  
someone downloading the release to understand what has changed since  
the previous release.

Thus, someone upgrading from IMP 4.1 to IMP 4.2.1 should be able to  
easily see a list of changes between those versions.  And someone  
upgrading from IMP 4.2 to IMP HEAD/5.0 should be able to quickly  
glance at the CHANGES file to see the differences between that path.

CHANGES is important from the perspective of an individual release,  
not a definitive history of every development event that has occurred  
in the project (many projects use this kind of changelog and, quite  
frankly, it is not very useful).  This is the only approach that makes  
sense.  Looking at the CHANGES file right now from the perspective of  
a HEAD release, it appears that caching has been added for both  
address parsing and address formatting which is blatantly incorrect.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]