[dev] Horde 5?

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Gunnar Wrobel <wrobel at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Ralf Lang <lang at b1-systems.de>:
>>>
>>>>>> I think we began changing the Wiki page to "Horde 4.1 not planned"
>>>>>> before it went into maint.
>>>>>
>>>>> I would love to start breaking BC and removing deprecated stuff, since
>>>>> it seemed like half of the work/fixes I did this evening was figuring
>>>>> out how to keep compatibility rather than fixing the problem.
>>>>>
>>>>> But I also think before we start work on Horde 5 we should probably
>>>>> decide on how (or if) to setup the git repo differently than what we
>>>>> currently have. Meaning: separate git repos for each
>>>>> application/framework going forward?
>>>>
>>>> Don't know if we shouldn't postpone this repo reorg to release time.
>>>
>>> I would vehemently disagree with this statement.  The time to  
>>> change repo structure must occur during the developmental window,  
>>> not right after the first stable version is released.  What if we  
>>> discover that we can't accommodate a new structure under Horde 5,  
>>> as released?
>>
>> We'd stick to the monolithic repository for Horde 5 then and would  
>> prepare Horde 6 in the splitted repository.
>>
>> Question is: Are there issues to be expected that will bite us  
>> later in case we go with a monolithic repo for the switch from  
>> Horde 4 to Horde 5?
>
> The major issue wouldn't bite us immediately, but it would affect  
> when we start doing Horde 6 development and start merging fixes back  
> into Horde 5.  This is the problem I recently ran into, and it broke  
> a bunch of stuff in IMP 5 due to major issues with a merge.

I think those are actually two very different issues, but I buy the  
issues with merging between Horde 5 and 6, see my other mail.

> These fixes were all bugfixes, but they didn't apply correctly to  
> IMP 5.0.  And since I no longer run IMP 5.0, I would have never  
> caught these issues save for the fact that one of my clients was  
> noticing problems.  That was a fortunate occurrence, not the norm.

Like I already mentioned in the earlier thread, you wouldn't have had  
those conflicts if you had correctly fixed bugs in master and then had  
them merged into develop with the regular merging. You might still  
have to adapt the fixes to the develop branch, but 1) you always have  
to adapt fixes anyway as soon as branches diverge and 2) you wouldn't  
have broken the stable master branch, just the development branch.

> And the reverse is true also.  I just noticed that the Edit As New  
> menu item I added to IMP 5.0 a few days ago got lost in 5.1 due to a  
> double conflict in a merge (e.g. stuff was merged from 5.1 -> 5.0,  
> this merge needed to be edited to work in 5.0, then when 5.0 was  
> merged back into 5.1 this commit got lost).

That's exactly the reason why you should implement things that need to  
live in both branches in the master branch first. There won't be any  
double merging. Exceptions from this rule are possible though if the  
changes are small enough to work in both branches without any  
modifications.

Jan.

-- 
The Horde Project
http://www.horde.org/