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

[Michael J Rubinsky]

Quoting Vilius Sumskas/LNK <vilius at lnk.lt>:

>> >>> 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.
>
> Why not?

Why wasn't I testing on 5.3.x? Because until this discussion, Git  
master was going to become Horde 6 - where we do plan on bumping the  
PHP requirement and quite frankly, don't see the value in testing new  
major release code on a version of php that was eol'd almost 2 years  
ago.

> Personally I think that bumping a required version "just because"
> is a very bad idea. Lots of folks use hosting providers which still has
> older PHP versions running and see no reason to upgrade. For example
> RedHat/CentOS 7.0 (which is newest) still comes with PHP version 5.4 by
> default. And they still support it. They also still provide PHP 5.3 for OS
> version 6.0 which is also fully supported. And I must remind you that
> these are most popular Linux distributions which are deployed in like half
> hosting providers worldwide.
>
> I would still be fine for Horde to require 5.4, but I really see no reason
> to do this. From the top of my head I don't remember any big changes which
> would really require PHP > 5.3. If you are worried that the code is not
> tested enough then so be it. Users can always submit a ticket to
> bugs.horde.org and in most cases it would be just a trivial fix anyway. It
> is far less time consuming then going though all hosting service desk
> loopholes and trying to update PHP version.
>
> --
>    Vilius
> --
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <https://lists.horde.org/archives/horde/attachments/20160616/5388b9cd/attachment.bin>