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

[Jan Schneider]

Zitat von Gunnar Wrobel <wrobel at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>>
>>>> What I still really don't like is getting rid of CHANGES entries  
>>>> in our git tree until after a release. I still say it is useful  
>>>> for seeing what framework packages have changed since the last  
>>>> release. Unless the component script can give us an easy way to  
>>>> output those changes, *before* the release process, I'd like to  
>>>> see us keep them. Keep them off the website if you like, but I'd  
>>>> like to keep them in our tree.
>>>
>>> How is this any different than looking at the package.xml file?
>>
>> Because I don't want to have to look at the package.xml file for  
>> every framework package to see which one has changes. The way it is  
>> now, with the framework changes in horde/docs/CHANGES it's very  
>> easy to see which package has had changes since the last Horde  
>> release. The Horde package.xml file did not contain these changes.
>
> The current plan seems to be to autogenerate the list of changes to  
> be put into docs/CHANGES right before a release. The same operation  
> could of course be done at any time in order to just display what  
> changed so far and what would be added to the CHANGES file if it  
> would be release time. So you would run a short components command  
> to get this list.
>
> Just to be certain that I understand what the functionality that  
> would be added to horde-components should be.
>
> We would ...
>
> 1) Reduce "horde-components changed" to only touch the package.xml
>
> 2) Add "horde-components changelog" that would
>
>   i) Determine the timepoint of the last package release either by  
> git tag or package.xml timestamp.
>
>   ii) Go to all first level dependencies of the package and  
> determine the releases since the above timestamp.
>
>   iii) Grab the changelog lines from the dependency releases that occured.
>
>   iv) Add or display those changelog lines - annotated with package  
> name and release version.
>
> Is that correct?

Sounds good.

> What seems to be a bit fuzzy are the dependencies that  
> horde-components should consider for this operation. I assume  
> "horde" is special and we wan't to consider not only the first-level  
> dependencies but rather the full hierarchy - at least as long as the  
> packages are prefixed with "Horde_". For the applications we  
> probably only want the first level dependencies but exclude "horde"?  
> And the bundles would get the full hierarchy?

Excluded in any case should be application-level dependencies.

Bundles can be done manually, because they need some massage anyway.

I tend to only include first-level dependencies for "horde" too. I'm  
afraid that Horde would be pulling almost *all* packages if we go  
through the full hierarchy of sub-dependencies. I think a test run  
would be helpful to see what this would include.

Jan.

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