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

[Vilius Sumskas/LNK]

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

No, I mean, why not keep the same requirement. PHP community do not 
support that version anymore, but as I said, all major Linux distribution 
providers still do (and they still backport security bugfixes).

In my opinion bumping requirements which are still used widely = market 
share lost. Deciding on a PHP version must be done before a code is 
branched, so it can be tested properly.

Anyway, as I said, if you are going to raise the required version then 5.4 
should be a best option.
 
> > 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.