[horde] Status Horde 5.3/6.0, official PHP7 Support, EAS 16

Torben Dannhauer torben at dannhauer.info
Tue Feb 21 22:46:53 UTC 2017

Zitat von Jan Schneider <jan at horde.org>:

> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>> Quoting "jan at horde.org (Jan Schneider)":
>>> Zitat von Torben Dannhauer <torben at dannhauer.info>:
>>>>> Quoting Torben Dannhauer <torben at dannhauer.info>:
>>>>>> Dear Horde Devs,
>>>>>> First of all I would like to thank you for your dedication to the
>>>>>> horde project in the last year - your project is a great piece of
>>>> software!
>>>>>> Since this year is soon over, I would like to take the chance to get
>>>>>> an update of the current status.
>>>>>> Some month ago, there was a discussion on the list how to go on with
>>>>>> Horde, wait until everything is done for Horde 6 or if it should be
>>>>>> released as Horde 5.3
>>>>>> What is the current status in this decision?
>>>>> Since the loss of the Basic view is too much for a point release, I
>>>>> think what we are leaning towards is releasing what we currently have
>>>>> as Horde 6, without any of the major BC-breaking refactoring we had
>>>>> planned for H6.
>>>>> IIRC, we need to still talk about what this would look like from a
>>>>> repository stand-point since we would now need maintain 2 stable
>>>>> branches, along with master. Horde 6 was planned to be released after
>>>>> we split the repository into individual repos for each component. I'm
>>>>> torn as to how I feel about this. One the one hand it gets new
>>>>> features out quicker, which absolutely has to happen, but it means
>>>>> delaying a bunch of BC breaking things and slowing future progress.
>>>>>> What type of work needs to be
>>>>>> done to get the release out. How can the community contributer to
>>>>>> speed up things?
>>>>> Jan and I need to go over this and see exactly what needs to be done
>>>>> to get the alpha releases rolling, and see what we can delegate out to
>>>>> our community supporters.
>>>>>> Additionally, PHP is moving more and more towards 7.0, so an official
>>>>>> support of the Horde project for PHP7 would be nice. I read in the
>>>>>> list that
>>>>>> PHP7 should basically work, also forcing packages to PHP7 is still
>>>> required.
>>>>>> I will test this out soon.
>>>>> I have an install running just this locally and, at least for my
>>>>> day-to-day use cases, works well - despite the WARNINGS that creep up
>>>>> in the logs.
>>>>>> What is required in detail to bring official PHP 7 support to all
>>>>>> packages to close this topic?
>>>>> I think while we can do what we can to increase PHP 7 support for the
>>>>> current release applications, we can never officially mark them as
>>>>> PHP7 - this will have to wait until H6.
>>>>> There are still some external libraries that we depend on that are not
>>>>> PHP 7 compatible. We will need to either find replacements for those
>>>>> libraries, or fork/refactor them under the Horde banner. This could be
>>>>> a non-trivial amount of work (not sure as I haven't personally looked
>>>>> at the code for these yet). The good news is that I believe we only
>>>>> have a few of these situations, like Text_Wiki in Wicked. We could
>>>>> always hold back the releases of these applications if needed in order
>>>>> to get the rest of the main groupware applications out.
>>>>>> As a last step: is EAS 16.0 finally implemented? What is a blocker to
>>>>>> release it (maybe even in the 5.2 series?)
>>>>> EAS 16.0 has been implemented for some time now, but requires both a
>>>>> client that supports it and our current git master code to make use of
>>>>> it. The current stable ActiveSync library supports it, but the
>>>>> 5.2 series of applications will not since it required significant
>>>>> additions/changes to the various application APIs.
>>>>>> What would it cost to implement EAS 16.1 [1] (including release as
>>>>>> official packages!)?
>>>>> I haven't looked at this, other than reading the generic description
>>>>> of things it's supposed to add. IIRC, it adds support for
>>>>> renegotiating meetings times and more atomic data wipes (so you could
>>>>> wipe just the exchange data and not the entire device, for example).
>>>>> For the former, this would mean that in addition to the ActiveSync
>>>>> changes needed, we would need to add support to Kronolith for iTip
>>>>> COUNTER/DECLINECOUNTER and SEQUENCE support [1]. Of course would also
>>>>> need a client that actually supports this to test.
>>>>> If we can get at least support in Kronolith and our iCalendar code for
>>>>> COUNTER/DECLINE etc...before Horde 6 then we could conceivably get
>>>>> this functionality in Horde 6.0 when the ActiveSync side of it is
>>>>> done. Otherwise, it would have to wait for 6.1/7.0.
>>>>>> Thanks again for all your input into the project!
>>>>> Thank YOU for all of your support :)
>>>>> [1]
>>>>> https://bugs.horde.org/ticket/8396
>>>>>> Warm regards,
>>>>>> Torben
>>>>>> [1]
>>>>>> https://blogs.msdn.microsoft.com/exchangedev/2016/06/13/announcing-ex
>>>>>> change-
>>>>>> activesync-version-16-1/
>>>>>> --
>>>>>> Horde mailing list
>>>>>> Frequently Asked Questions: http://horde.org/faq/ To unsubscribe,
>>>>>> mail: horde-unsubscribe at lists.horde.org
>>>>> --
>>>>> mike
>>>>> The Horde Project
>>>>> http://www.horde.org
>>>>> https://www.facebook.com/hordeproject
>>>>> https://www.twitter.com/hordeproject
>>>> The core apps all seem to work fine with PHP 7. I'm running IMP,
>>>> Turba, Ingo, Kronolith, Nag and Mnemo without issue.
>>>> Tim
>>>> Hi Tim,
>>>> thanks for your status report! It seems the only failure is  
>>>> Wicked. Since I
>>>> use it internally for all documentation, it is a major point for me.
>>>> Mike mentioned Text_Wiki - it seems it is unmaintained currently:
>>>> pear.php.net/package/Text_Wiki/.
>>>> Unfortunately my PHP knowledge is limited to basic skills, I think I'm not
>>>> competent enough to maintain that package. Does Wicked support a different
>>>> backend? Maybe there are nice PHP7 compatible and still  
>>>> maintained backends
>>>> available wicked could switch to?
>>> Wicked works just fine on PHP 7. You can safely ignore deprecation or
>>> strict messages from PHP.
>> Is this still true? Text_Wiki uses a bunch of reference assignments  
>> when creating new objects. This is no longer supported in PHP 7 and  
>> issues a fatal error. See  
>> http://php.net/manual/en/migration70.incompatible.php
>> I've tested this locally using all of the available Text_Wiki_*  
>> formats with the same result. After manually editing the code and  
>> removing the reference assignments would allow it to work.
> Yes, looks like you are right. Seems I have a patched version  
> installed already.

I had to patch it as well for PHP 7.0.15 - but this was trivial.

regards, Torben

More information about the horde mailing list