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

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

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

I agree with what you are saying to a certain extent. I find myself  
sometimes getting confused regarding our releases. We release  
framework packages independently - with version numbers that do not  
relate to the version of Horde as a whole - when the situation demands  
it. On the other hand we also talk about "Horde 4" (or 4.1 or 5 or  
...) in the context of a coordinated release that contains all the  
framework packages. We also use this coordinated version number as a  
way of determining/enforcing BC.

When building releases, or even discussing bugs/missing functionality  
with our users, it is EXTREMELY helpful to have a single place to  
include these changes. If you are looking for the authoritative  
changelog for a single package, look at package.xml. If you are  
looking for an overview of what has changed in "Horde 5", look in  
CHANGES.

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

I'm not sure I would agree with putting these entries in _every_  
application. This would still lead to having to look in multiple  
CHANGES files, as well as potentially having the same entry appear in  
_every_ application. How about introducing a new changelog file, that  
lives in Horde that contains only framework related changes?  Still  
not ideal, but maybe a compromise that we can all live with?


-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org