[dev] [commits] Horde branch mnemo_4_1 updated. 7324877f91d83f8de26d41ba7ca05be559255994

[Jan Schneider]

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>:
>>
>>> The branch "mnemo_4_1" has been updated.
>>> The following is a summary of the commits.
>>>
>>> from: 06823ed8f9c38538ca7cab30b6594cd87a5b6c4d
>>>
>>> 7324877 Remove 4.1 changelog
>>>
>>> -----------------------------------------------------------------------
>>>
>>> commit 7324877f91d83f8de26d41ba7ca05be559255994
>>> Author: Michael J Rubinsky <mrubinsk at horde.org>
>>> Date:   Thu Mar 21 13:26:49 2013 -0400
>>>
>>>   Remove 4.1 changelog
>>>
>>> mnemo/package.xml |   13 -------------
>>> 1 files changed, 0 insertions(+), 13 deletions(-)
>>>
>>> http://git.horde.org/horde-git/-/commit/7324877f91d83f8de26d41ba7ca05be559255994
>>
>> Er, no. If anywhere, it needs to be removed from the main changelog  
>> entry. The entries at the bottom merge just fine and are needed to  
>> rebuild the main entry once we merged back.
>
> I probably gave mjr the wrong idea since I may have removed the  
> wrong block from imp_6_1's package.xml.  But we do need a way to add  
> entries to the changelog package.xml entry automatically (using  
> horde-components) without adding it to the currently active notes  
> block.
>
> I implemented this last year:
> http://marc.info/?l=horde-dev&m=132761537203506&w=2
>
> But that doesn't quite do what it needs to do.
>
> But I disagree that we should not be adding entries to docs/CHANGES.  
>  If anything, that should be the ONLY place to add since that's the  
> only place a reasonable person is going to look if they want to know  
> what has changed between the versions.

Depends on whether they look at development versions for future  
changes, or to released versions. The package.xml changes show up in  
the pear channel's feed, and with your patches on the main site too.  
Since you added the changelogs to pirum, I probably misunderstood you  
here. Could be the double negation ;-)

>> I still prefer to have the main entry in the branches filled with  
>> the correct changelog entries too, fixing conflict during merging  
>> is really not so much work, just repetitive.
>
> I still think we need to look at making master the git HEAD branch  
> and having "release" branches.  This helps with merge conflicts  
> since those who commit a general fix to the release branch also have  
> to concurrently commit such a fix to the master branch, and they are  
> in the best position to resolve merge conflicts rather than having a  
> later committer try to figure this out later.  This would also  
> enforce the fact that only bug fixes should go into the release  
> branch, since its a PITA to have to make multiple commits if you are  
> developing something that is a new feature instead.

Those are good points pro your argumentation for a different branching model.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/