Drop support of too old PHP versions

More hosts now support multiple php's today though. For example I use cloudlinux on my servers, and I have 5.3,5.4,5.5 and 5.6 as options available. Eventually I will drop 5.3 support but for now it's not a huge issue. I do get there is some hosts using older systems. It really only benefits people unwilling to update they're websites, and in the world of development this shouldn't be a factor, since the chances are people using CI with a new version of php support are likely to be going for newer technologies. In the cases of hosts not supporting those newer technologies that's they're fault.

PurdyDesigns Website Design, Development. Also Including Web Hosting. Print Media, server deployment and management, and more!

There really is no excuse for running a business and taking people's money and data and not using a secure infrastructure.

If:

• an Operating System
  
• a Framework
  
• or a Language
  

has reached the end of its life and is no longer being updated, with security patches, bug fixes and the like, it is time to move onto a system that is.

There are too many companies and organizations, which are running fast and loose with peoples personal data and financial information.

And getting away with it!

Or at least, seem to be getting away with it.

There is no excuse for being lazy, cheap or depriving developers or a revenue stream, after all, it is what runs their business in most cases.

I think the original poster is onto something.

PHP 5.3 is already end of life.

Is it a good idea to encourage people to continue with outdated and insecure foundations to what are generally a hostile environment on the internet at large?

I wouldn't say that. CentOS 6.x ships with 5.3.3 and it's considered one of the most secure, stable platforms out there.

If they jump to 5.5+ we'll have to rewrite our apps. Until it's necessary I don't see a point in forcing that on everyone who wants to continue using CI.

If they jump to 5.5+ we'll have to rewrite our apps. Until it's necessary I don't see a point in forcing that on everyone who wants to continue using CI.

That's really your problem and not anyone else's. Besides, going from 5.3 to 5.6 isn't that much of a big deal. I did it. Everything kept working fine.

I keep on saying. Let CI 3.0 be the last version on 5.3.3. CI 4.0 can be 5.5/5.6. You cant expect people on shared hosting or legacy applications to upgrade. Just keep on applying security patches to CI 3.0 and let them rot.

Rackspace Cloud sites offers the choice of either 5.3 or 5.4

Minimum PHP version support is always related to what technologies are in use...

PHP 5.4 - I think this should be the minimum - using NameSpaces(5.3) and Traits in next CI will be very important because without NameSpaces CI will be lost in future. All new libraries everywhere today are building using NameSpaces. And not to have such structure and full support (autoloading and etc..) is a big minus..

PHP 5.5 provides things as generators , password hashing api and a few other good things which are nice to be in use.
I am not quite sure that those things will be so helpful but we can think for using this as minimum standard.

PHP 5.6 - This is too new final version and it is the last one from PHP5 era .. So I am not sure that it must be Minimum at all..

Best VPS Hosting : Digital Ocean

If they jump to 5.5+ we'll have to rewrite our apps. Until it's necessary I don't see a point in forcing that on everyone who wants to continue using CI.

That's really your problem and not anyone else's.  Besides, going from 5.3 to 5.6 isn't that much of a big deal.  I did it.  Everything kept working fine.

So you would consider this an easy transition: CI rewrites v4 using the new features in PHP. Namespaces, traits, closures. Or they could go really bleeding edge and use generators. Presumably they'd also embrace auto-loading, meaning the $this->load pattern will not exist. Every controller and model in your project will require changes. All existing addons will break and require updates.

That is not a decision that should be made lightly, especially considering CI's past upgrade requirements.

While I agree that Namespaces is a must for the next v4, how much of the rest is needed for a framework to use? As long as it doesn't prevent you from using those features in your app, the framework itself doesn't need to. Heck, I regularly run CI 2.x sites on PHP 5.4 and 5.5 servers with no issues.

For example, traits. I'm not sure I see any place in what CodeIgniter provides that would benefit from that. In a larger codebase that provided templating or Auth built-in then, yeah, perhaps.

Closures are very nice for some things, but they really came in 5.3 so 5.3 seems like the magic number to me.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials

So you would consider this an easy transition: CI rewrites v4 using the new features in PHP. Namespaces, traits, closures. Or they could go really bleeding edge and use generators. Presumably they'd also embrace auto-loading, meaning the $this->load pattern will not exist. Every controller and model in your project will require changes. All existing addons will break and require updates.

That is not a decision that should be made lightly, especially considering CI's past upgrade requirements.

Lets take a step back.  Just imagine there is no CI 4.0.  You wanted the new features in PHP.  What would you do?  Oh yeah, so you would have to move to laravel and symfony.  You would have to migrate your code.

So that said.  Why not have CI 4.0 be the same thing?  CI really needs to move things forward.  Why should developers who are happy to migrate their codebase because its in active development be constrained because of developers like you who want an upgrade path when it makes no sense to do so.

Like I say.  Keep CI 3.0 as the last version for everyone to use.  Keep on updating it and then those guys will be happy.  Have an entirely new CI 4.0 branch and let those who can easily upgrade, upgrade.  If you can't stay on CI 3.0.

It's like Microsoft keeping 8bit libraries for those who keep on developing for Windows 3.1.  There's a point where it needs to be cut from the software base.  

Closures are very nice for some things, but they really came in 5.3 so 5.3 seems like the magic number to me.

Yeah nevermind that according to PHP http://php.net/eol.php it says:

5.3 14 Aug 2014 3 months ago 5.3.29

Oh but wait, if you are on CentOS 6 sure, 5.3 will be supported until 2020. Nevermind that if you are in active development, servers have already been upgraded to 7 and php 5.4 is available.

Seriously, CI is not going to go anywhere except being a niche framework if this mentality of the race to the bottom continues.

Lets take a step back.  Just imagine there is no CI 4.0.  You wanted the new features in PHP.  What would you do?  Oh yeah, so you would have to move to laravel and symfony.  You would have to migrate your code.

First off - I'm not saying that my opinion is the opinion of the group or what will happen with 4. So don't take any of that as gospel, just my current thinking.

Second - you conveniently ignored the preceding paragraphs when you plucked that quote out. I'll reiterate here. There's nothing stopping you from using CI with any version of PHP you want. As far as I know there's no blockers up to and including 5.6. Do whatever you want with your own code. It's a free world and depends on the needs of your project. But which of those features, other than the two I named, closures and namespacing are needed in the core framework for the rest of your code to play well with more modern development practices? Autoloading - sure, v3 already has a (tiny) step toward that. But that happens in 5.3 also. Generators? While potentially nice, not needed in the core framework as far as I can tell.

Or am I missing something?

And frankly, even Laravel only requires 5.4 last time I checked. There's a huge difference between what the framework forces you to use and what you use in your own project. And there's typically a huge difference between what PHP Internals has decided to support and what hosting companies provide. Again, if the project demands it, you'll have your own server and can do whatever the project demands, including using generators or any other newer features in your own code.

But the sticking point here is WHAT WILL THE FRAMEWORK FORCE YOU TO USE? And how many potentially useful projects will need to go find another home if we force 5.6 on them.

One path that I could see being viable, if the community demanded it and was willing to seriously step up and help out, would be to have a 4.0 with all of the bells and whistles, while maintaining an LTS version of 3 for older PHP versions. But the team that actually contributes and maintains the repo is extremely tiny at the moment and none of them get paid to do anything.

Once 3.x is out the door we can talk more seriously about plans for 4. In the meantime, use any version of PHP you want. CI will still work with you.

Support Development •  CodeIgniter 4 Foundations • Practical CodeIgniter 3  • CodeIgniter Tutorials