2.0 - Dropping PHP 5.3 Support

[Michael Babker]

With efforts on getting packages up to 2.0 underway, one of the things that should be looked at is PHP 5.3 support.  With it having just gone EOL, should the 2.0 packages be required to continue supporting it or can we look at dropping support for it?

[Dmitry Rekun aka b2z]

+1
Dmitry

[George Wilson]

Personally I don't see an issue with 5.3 support. There are many hosts still on it. Plus as far as i know there are very few areas where it would make a difference. Even the json serializable stuff wouldn't be able to be fixed with the PHP5.5 & linux mess.

Also if we want to encourage more people to contribute we should be reassuring people latest and greatest features will still end in the CMS, because at the end of the day CMS contributors are going to be the majority of the contributors for the foreseeable future. Just because the CMS can still use v1.0 for composer, it doesn't really encourage people to submit features to the framework which go into v2.0 and we see in the CMS 5 years later when we move to v4.0 of the CMS...

Kind Regards,

George

[Michael Babker]

I knew that was coming ;-)

So I am thinking a few things here.  One of them is think beyond the CMS; ya right now it's biggest contributor crowd might be those already using that, but if we want to allow the Framework to grow beyond the Joomla circles, the Framework needs to not be held completely back by supporting the CMS (there may be a time and place for that argument, I just don't personally see this as an issue).  Next, dropping 5.3 support wouldn't mean we refactor all the things to break 5.3 support, but newer contributions wouldn't need to support it.  Last larger item on my mind right now is long term planning; if we were pushing all the packages to 2.0 this week then this discussion would probably be a moot point but realistically we're looking at some time (at least a few months if we take a look at some of the threads on this list and throw around newer ideas) before they're released so do we really want to release a new (what should be long-term supported) series that's supporting EOL software?  With Ubuntu's LTS release this year, a lot more folks are upgrading from PHP 5.3 to 5.5 (IIRC that's what 14.04 is shipping) now so the 5.3 use numbers should start going down.

--
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

[Ben Tasker]

> With Ubuntu's LTS release this year, a lot more folks are upgrading from PHP 5.3 to 5.5 (IIRC that's what 14.04 is shipping) now so the 5.3 use numbers should start going down.

Except that a lot of hosts won't bother updating for quite some time. Sure, anyone running their own systems should be off 5.3 reasonably soon, but it'll be some time before some hosting services upgrade. We can argue that they're crap hosts, but from a users perspective, if the software they want to use doesn't work on their hosting, it's the software that's crap. That's only going to be made worse if they're using something else that continues to work on 5.3 (and/or won't work on later versions)

> Next, dropping 5.3 support wouldn't mean we refactor all the things to break 5.3 support, but newer contributions wouldn't need to support it

The effort/work differs, but the end result is likely the same. At some point a contribution that doesn't work with 5.3 gets made and framework potentially no longer works on 5.3.

Longer term, 5.3 support isn't something that shouldn't have too much energy put into it. But IMHO, really 6 months after EOL is the absolute earliest any breakage should happen, and even then it's likely some hosts won't have updated.

--

Ben Tasker
http://www.bentasker.co.uk

One Server to rule them all,
One Ping to Find Them,
One LAN to bring them all,
And in the darknet BIND them.

- The Tolkien Ring Network

01001001 01100110 00100000 01111001 01101111 01110101 00100000 01100011 01100001 01101110 00100000 01110010 01100101 01100001 01100100 00100000 01110100 01101000 01101001 01110011 00100000 01111001 01101111 01110101 00100000 01100001 01110010 01100101 00100000 01100001 01110011 00100000 01110011 01100001 01100100 00100000 01100001 01110011 00100000 01001001 00100000 01100001 01101101

[Nils Rückmann]

Let's face it. Nobody uses the Joomla! Framework today. So BC is not a big issue.

+1 For building something new on a not-out-dated ground.

[Michael Babker]

Looking around the marketplace some (both CMS and Framework), there's already folks not supporting 5.3.  Us supporting 5.3 allows us to hit that piece of the market others are missing because of it, but how long would we then continue to support it past its EOL?

I kinda like the approach Aura took with their v2 code.  If it can support PHP 5.3, then make it so, but 5.4 is where they guarantee support.  Considering our code is already written against and supporting 5.3, I'd envision that we'd still end up with a product that's mostly supporting that environment.  Another thing to consider too is that Framework 1.x will most likely in some form live on as long as CMS 3.x with us looking at trying to backport some of the Framework code into that application.  Folks really needing PHP 5.3 support will be able to find it, but I think newer development and refactoring shouldn't have to consider that environment.  Of course, if I'm in the minority, I'll happily shut up and go about my merry way; I'm just trying to get a feel for opinions right now and not just make a decision and force people to live with it ;-)

[Matt Thomas]

On Tue, Sep 2, 2014 at 3:28 PM, Michael Babker <michael...@gmail.com> wrote:

Considering our code is already written against and supporting 5.3, I'd envision that we'd still end up with a product that's mostly supporting that environment.

I was wondering about that myself. Seems like a fair approach to me.

Best,

Matt Thomas

203.632.9322
http://betweenbrain.com/

[Nils Rückmann]

Am Dienstag, 2. September 2014 20:24:16 UTC+2 schrieb Ben Tasker:

Longer term, 5.3 support isn't something that shouldn't have too much energy put into it.

It's a big problem because it keeps Joomla! from using new features like traits. 

 

But IMHO, really 6 months after EOL is the absolute earliest any breakage should happen, and even then it's likely some hosts won't have updated.

That's more general (so please don't take it personal), but i'm really annoyed at people (especially customers) which wants to wait after EOL. EOL ist an ultimative deadline there is no "after EOL". Just recently a customer asked me to migrate his site to Joomal 2.5 .. They will never understand it if we don't force them.

[Ben Tasker]

> That's more general (so please don't take it personal), but i'm really annoyed at people (especially customers) which wants to wait after EOL

I don't disagree with your view, for me EOL _should_ be an absolute watershed, but sadly it's not the world we're living in. Look how long it took for us to be able to safely assume that most were using 5.3 (or later). 

> EOL ist an ultimative deadline there is no "after EOL"

In that context, I should have included "ing". There is no after EOL, but there is an after declaring EOL.

--

Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-frame...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.

[George Wilson]

On Tuesday, September 2, 2014 8:28:19 PM UTC+1, Michael Babker wrote:

Looking around the marketplace some (both CMS and Framework), there's already folks not supporting 5.3.

True :)

 

Us supporting 5.3 allows us to hit that piece of the market others are missing because of it, but how long would we then continue to support it past its EOL?

I mean this is the biggest issue as I see it. If we had a large user base then sure. But we don't, we need all the market share we can get, and then a bit more. Also the how long past it's EOL is the big counter issue...... *shrug* 

 

Another thing to consider too is that Framework 1.x will most likely in some form live on as long as CMS 3.x with us looking at trying to backport some of the Framework code into that application.  Folks really needing PHP 5.3 support will be able to find it, 

But realistically we'll probably be at Framework v3.0 before that happens.

but I think newer development and refactoring shouldn't have to consider that environment.

I mean having traits could allow us to rewrite MVC again. I would be interested in seeing if we could do multi-task controllers with single-task traits etc. and I'm sure there are other things of interest as well we could do.

  Of course, if I'm in the minority, I'll happily shut up and go about my merry way; I'm just trying to get a feel for opinions right now and not just make a decision and force people to live with it ;-)

What I would say is that there's nothing literally right now that requires 5.4 to make things infinitely better and if we can simplify code we can do that after release/just before release when we have the main re factoring efforts complete for the packages that need it.

But also ditto with me :) I'm not hugely fussed either way. Just putting it out there. I'm also more than happy to re-evaluate when framework 2.0 actually hits the shelves.

Kind Regards,

George 

[morten hundevad]

I am in process of doing just that. =)

https://github.com/jfusion/org.jfusion.framework

Tho still work in progress

-Thanks

[Sven Versteegen]

Except that a lot of hosts won't bother updating for quite some time. Sure, anyone running their own systems should be off 5.3 reasonably soon, but it'll be some time before some hosting services upgrade. We can argue that they're crap hosts, but from a users perspective, if the software they want to use doesn't work on their hosting, it's the software that's crap.

Anyone who is running their own system should be able to handle an update to a newer php version or to run more than one version, if not, they should not running their own system.
Hosts who care about their clients support more than one version or they are at least on 5.4.x already.
Hosts who don't care to update or not supporting more than one version are crap, we don't have to argue here it's a fact...
But hey that's just my opinion.

I just checked a clients account I've setup with 1&1, default version right now 5.4.32, the funny thing is in their control panel I can choose 5.6, 5.5, 5.4, 5.2 but there is no 5.3 right now^^

[Cyril Thibout]

I do agree with those just telling BC is not a big issue since nobody uses the framework now.

If we want to push the framework as a real PHP dev tool just like any other framework we must set it on stable and modern basis. Drop PHP 5.3 :)

 

[Walt Sorensen]

Definitely drop 5.3 as it is a year past it's end of life

5.4 is questionable since it's EOL is this fall (2015), but would be the lowest acceptable minimum

5.5 would be a preferred minimum even with the EOL in Summer 2016

I will say that there is an interesting option  for testing with Travis CI. We could target a minimum of 5.4 or 5.5, but still test 5.3 as an allowed failure (with a comment that 5.3 is not officially supported).
If there was something in the v2 refactoring that breaks B/C we would know about it but wouldn't necessarily need to deal with it.
Of course there are some interesting B/C breaks from php 5.3 in 5.4 and some interesting new features that might suggest not caring to test 5.3 as an allowed failure.

[Michael Babker]

Right now I'm not thinking of setting an arbitrary minimum version Framework wide, but letting possible features and refactorings start making decisions.  One of the first bumps would be if we kept the Session package and refactored it following PHP 5.4's SessionHandlerInterface, and I think that would start a domino affect of sorts (it would bump the Application package, which would bump the OAuth packages, which would bump the social packages...).

I do agree we need to officially discontinue PHP 5.3 support, it's EOL.  I think it's safe to push past PHP 5.4 too given its EOL this year.  From what I know, many of the *nix LTS packages are at PHP 5.5 or 5.6 now and good hosts are updating to those LTS releases or offering the later PHP versions, so targeting 5.5 seems fair for a long term thing.

--

[Andrew Eddie]

My personal opinion is that each contribution is assessed on it's merits and that the developer should strive to use the lowest practical version of PHP possible, but no lower. In some cases, that may mean the code is backward compatible to PHP 5.3. In other cases, PHP 5.5 may be required. I don't think you can set a hard version anymore because PHP doesn't move nearly as slowly as it once did.

Regards,

Andrew Eddie