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

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

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

Correct.

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

Nobody will be upgrading from 4.2 to 5.0, but rather from something  
like 4.2.8 to 5.0. This is an important difference.

> 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

I agree.

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

No matter what has changed between two branches, the changes between  
4.2 and 4.2.1 will stay the same until the end of time. It doesn't  
matter if you run 4.2.1, 5.0, or 9.0. The changelog for old versions  
can't change by definition. If you are really picky about this, you  
can change the 5.0 entry to say something like "Replace address  
formatting caching with address parsing caching." We don't remove  
features that often, but if we do, we don't document this by removing  
some changelog entry from IMP 1.2 where this feature may have been  
added, but by adding an entry that says which feature has been removed.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/