[horde] [dev] Horde 6 vs. Horde 5.3

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> This discussion is actually better taking place on the horde  
>> mailing list, since we want feedback from our community too, so  
>> moving it there.
>>
>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> Hi,
>>>>
>>>> since we have been asked recently when to expect Horde 6, and  
>>>> what could be done to speed up its release, I'd like to discuss  
>>>> an alternative option to release Horde 5.3 first.
>>>>
>>>> Many new features have gone into master since the Horde 5.2  
>>>> release, few of them sponsored by clients or contributed by the  
>>>> community. The expectation to see those features in a stable  
>>>> release within a foreseeable timeframe is more than justified.
>>>>
>>>> We could speed up the Horde 6 release by additional sponsoring,  
>>>> but it's not only a matter of money, but also a matter of  
>>>> developer resources. With Michael and me being the only remaining  
>>>> active core developers at the moment, we rather lack developer  
>>>> time. Especially for core development like infrastructure stuff,  
>>>> namespace refactoring etc. that are not easy for contributors to  
>>>> jump in.
>>>>
>>>> AFAIK we don't have any BC breaks in master yet, at least none  
>>>> that couldn't be solved with bumped dependencies. So doing a 5.3  
>>>> release should work. Michael, please correct me if I'm missing  
>>>> something.
>>>>
>>>> The flipside is, that:
>>>> - Horde 6 will delay even further
>>>> - we won't be able to do any refactoring, e.g. switching to namespaces
>>>> - we won't have a repository split that would make the libraries  
>>>> more attractive, e.g. by being available via composer/packagist  
>>>> and thus attracting external developers
>>>> - we won't be able to do long-anticipated BC breaks that  
>>>> currently hinder some development
>>>>
>>>> The discussion is open.
>>>
>>> I actually had a similar email in my drafts folder for a while  
>>> now, trying to compose the argument to do this or a "quick" Horde  
>>> 6 release as-is - without the repo split.
>>>
>>> All in all, I'm mostly for it, with the following concerns:
>>>
>>> IMP in master is already labeled as 7 (not that this can't be  
>>> changed). There is a slight API change in IMP, but from what I  
>>> understand from Michael S.  the data that is now no longer  
>>> available isn't data ever meant for public consumption anyway  
>>> (though it IS still a BC break). To my knowledge the only Horde  
>>> code that had used this bit of information is ActiveSync, but it  
>>> was refactored to use the new data anyway.
>>>
>>> Then there is the fact that the basic and minimal views were  
>>> completely removed in IMP and this might be too big a change to  
>>> include in a point release.
>>>
>>> A point release will definitely hold up the work needed to get  
>>> Horde 6 rolling. The need to support the versions we need to, plus  
>>> the lack of time will hold up the repo split.
>>>
>>> My biggest gripe would be the delay in being able to start  
>>> ActiveSync refactoring. There are a lot of things that need to be  
>>> changed to make it more attractive to other developers. This might  
>>> be a blessing in disguise though, since it IS so much work,  
>>> getting an interim point release out now would prevent my  
>>> refactoring from holding up any major release.
>>>
>>> All that being said, I think the need to get Kronolith out, with  
>>> the oft-requested fixes for scheduling, probably trumps all other  
>>> concerns at this point, so I would say lets do the 5.3 release,  
>>> with the understanding that nothing new gets added until the repo  
>>> split happens.
>
> Another thought. Will we be able to (do we have to) keep the PHP  
> version requirement the same? Personally, I've not been testing  
> master against PHP 5.3.x.

No, we can safely bump the PHP version, though we shouldn't push it  
too far, if we don't want to do any refactorings that require or  
benefit from new PHP features, anyway.

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