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

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

That's what the components script is for. And we would lose upcoming  
changes like http://www.horde.org/apps/imp/docs/CHANGES.

Jan.

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