[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 Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>> That's what the components script is for. And we would lose  
>>>>> upcoming changes like http://www.horde.org/apps/imp/docs/CHANGES.
>>>>
>>>> So?  IMHO, this is confusing... the website documentation should  
>>>> not be showing changes that don't exist yet (from a stable  
>>>> release point of view).
>>>
>>> I think it's helpful for users to see which fixes will be in the  
>>> next version without having to get into the source repository.  
>>> Kind of a roadmap.
>>
>> FWIW, I agree with Jan here. This is a useful resource for users  
>> that do not track every commit.
>
> Not to be difficult, but I entirely disagree.  My first reaction on  
> going to the CHANGES page on www.horde.org was that the page was  
> either broken or we were pointing to the wrong CHANGELOG file.
>
> Jan said it himself: if this is meant to be a "roadmap" view, then  
> it needs to be on the page we have specifically for that (Roadmap).
>
> I can't think of another project that does things this way.  Just a  
> real quick check... but Git, Mozilla, PHP, PEAR packages, Dovecot  
> all list changes for the current stable version, not prospective  
> changes in a yet-to-be released future version.
>
> It seems like the following would be a better solution:
>
> * Make all changelog entries in package.xml only
> * docs/CHANGES is auto generated from package.xml when building a release
> * The documentation page on www.horde.org shows the changelog AS OF  
> THE LAST STABLE RELEASE
> * We dynamically generate the list of changes available in the NEXT  
> version and display it on the roadmap page

While I don't fully agree, I could live with this solution. That is,  
putting the x.x.x git changelog entries on the roadmap page. While  
we're at it, maybe even tie in the whups tickets with the appropriate  
milestone entry set, though those milestones seem to be rather loosely  
interpreted sometimes ;)

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.

-- 
mike

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