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

[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>:
>>
>>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>>
>>>> As I replied before, I agree. This seems like a great compromise.
>>>
>>> Okay, Michael (S), since you started this discussion, are you  
>>> happy with this solution too?
>>
>> Reading through this thread as best as possible:
>>
>> I think it is a valid compromise.  I would, however, not mind  
>> seeing these changes in applications also.  I realize it is  
>> duplicative, but it would be very useful to look at the IMP  
>> changelogs and learn that an IMAP Client bug would be fixed if  
>> upgrading IMP/framework packages without needing to go to Horde and  
>> search through all the changelog entries.
>
> How about we only include the changes from those components that are  
> dependencies of this application but *not* of Horde? This would for  
> example add the Imap_Client changes to IMP but not Horde, and  
> Horde_Core changes to Horde but not IMP.

That might be a valid compromise.  At least for IMP, the critical  
packages are the Mime and Imap Client packages (maybe also the  
Text_Filter packages also), since changes there will be immediately  
noticable in IMP's UI.

The counterargument is that something like a change/fix to the Auth  
package, which might only affect the login screen for apps that  
require auth, will only show up in Horde.  But I agree that we need to  
draw the line somewhere.

>> Not really sure the reasoning why we could not include the version  
>> number of the current framework PEAR packages.  If we always  
>> release packages before apps, this information will be current.
>
> The idea was to include the changes at commit-time, not at  
> release-time. Though I don't recall the reasoning for that at the  
> moment.

Maybe to provide an instant snapshot of the current state of an  
application?  But I would argue just the opposite - CHANGES should  
ONLY be updated during the release process from package.xml data.   
This would eliminate the duplicative, time-consuming process of making  
two identical changelog entries in two different files.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]