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

[Michael M Slusarz]

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

michael

___________________________________
Michael Slusarz [slusarz at horde.org]