[dev] [commits] Horde branch master updated. 4fd2c31bf65accb6717f1330cbd8cc2b3ef1c9ba

[Michael M Slusarz]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Please add a changelog and bump the minor api and package version.
>>
>> Sure thing. Can someone refresh me on the current best practice for  
>> doing so (package vs. horde CHANGES), and if there's a components  
>> helper to do so?
>
> Application changes go into both the app's package.xml _and_ the  
> apps' CHANGES file. For framework libraries, the change log goes  
> into the package's package.xml file as well as the base horde app's  
> CHANGES file.

I (still) vehemently disagree with the latter statement.  It is  
tremendously confusing to put changelog entries in horde for things  
that don't live in horde.

Sure enough, I was completely confused by a recent changelog entry  
that appeared in the horde changelog.  I think mjr fixed something in  
Horde_Imap_Client, but then put a changelog entry in Horde.  Besides  
the fact that this really makes no sense from a practical standpoint  
(Horde_Imap_Client is *completely* independent from Horde the  
application), it also made no sense because the fix affected nothing  
in Horde.  It affected nothing in framework for that matter (outside  
of the Imap Client package).  I spent a good amount of time trying to  
figure out what this fixed in Horde, and I'm probably the person most  
familiar with the imap code.  That is a terrible sign if that occurs.

I understand the motive to put everything into a single, easily  
discoverable location.  But you simply CAN'T do this if the underlying  
theory is unsound.  Which it is here.  We made the decision to make  
framework packages != horde the application.  So we can't use the  
Horde changelog for these entries.  That is the unfortunate, but  
necessary, side effect of that decision.

A possible alternative: a script that gathers all changelog entries  
from packages relied on by an application that have changed since the  
previous release date of the prior application version.  But these  
entries must be logically/physically distinguished from the changes  
made in the horde application itself (i.e. files living under horde/  
in the master repo).

michael

___________________________________
Michael Slusarz [slusarz at horde.org]