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

Michael M Slusarz slusarz at horde.org
Mon Mar 25 04:29:56 UTC 2013


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.

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

michael

___________________________________
Michael Slusarz [slusarz at horde.org]



More information about the dev mailing list