Bump docs to suggest 5.3 is used #3450
Conversation
|
Ok, I had to do some rejigging of the branch there but we're good now. So. Why 5.3.3? Well... it's what Symfony use for their components, even though the newer versions will go higher. |
|
Go 5.4. 5.3.3 is EOL and dead. Go with a supported version. |
| - PHP version 5.2.4 or newer. | ||
| - PHP version 5.3.3 or newer. | ||
|
|
||
| CodeIgniter is tested on PHP 5.4, 5.5, 5.6 and the latest version of HHVM. Use the latest stable version |
There was a problem hiding this comment.
This is the least find-and-replace bit I did. It's an important message, to remind people to upgrade to later versions. Most wont bother I know, but many will.
|
If you're going to bump to 5.3.x I would suggest 5.3.23 which I believe is the earliest version that has the serious security flaws patched. Obviously 5.4 is better as it's not EOL, but 5.3.3 has known security holes. |
| this requirement. If PHP 5.3 or 5.4 functions or features are used then there | ||
| must be a fallback for PHP 5.2.4. | ||
| must be a fallback for PHP 5.3.3. | ||
|
|
There was a problem hiding this comment.
@philsturgeon this bit does not make sense anymore. May want to reword it.
|
@GeeH I'd be ok with that, I'm happy to update the PR if the team here are ok with it. 5.3.29 is the last in the 5.3 line so 5.3.23 is not overly aggressive. @scottrobertson I fixed that weird wording. Sorry, I had it fixed before but had to start the damn PR again as my new job |
|
A lot of projects use 5.3.3, because that's what the current version of Centos 6.5 comes with, so that's often found in the wild. (Did I mention that it is in fact the current version of Centos 6.5 that comes with this?) |
|
That’s pretty nuts. Consider me completely ignorant to the world of CentOS, but it seems to be on 7.0 and 6.6 now. How much weight should be added to the decision based off of 6.5 being using 5.3.3? |
|
That is nuts, it was stuck on 5.3.3 when I was using CentOS in the wild 2 years ago.I completely understand your reasoning, but given the security holes in 5.3.3 you might as well stay on 5.2 unless you're going to bump beyond 5.3.23 to be honest. |
|
Ah, I haven't been up to speed on Centos either. I only look into it, when people complain to me about it. What they do is that they backport all security fixes (and only the security fixes) into 5.3.3, and tack along a RHEL / Centos 6.6 still comes with PHP 5.3.3, and has an EOL in 2020. |
|
Ok. It’s obviously not my call but I’d recommend sticking to 5.3.3 (CentOS you bastards) and strongly suggest that 5.3.23 or over is used. I’ll add a note to the requirements page suggesting this. |
|
5.3 is dead, go with 5.4, stop living in the past. 5.2, I don't even... |
|
@devantoine I did politely ask that people don't harp on about 5.4. One jump at a time. 3.1 or 4.0 can be 5.4. |
|
Ha, the use of the third argument in get_html_translation_table() means that actually 5.3.4 will be required. Builds are failing on 5.3.3. Version check, or raise to 5.3.4? If we're going past 5.3.4, do we say f**k it and dive to 5.3.23 as @GeeH suggested? |
|
@philsturgeon Ain't "one jump at a time" the issue here? I'm aware about 5.3 usage, but even Debian stable ships with 5.4 now. I just found it bad to set the minimum version to a dead one, but I get your point, and may be too optimistic. |
|
Remember how CodeIgniter supported PHP 4 for f**king ages after 5.0 wasn't even supported? CodeIgniter has always been about supporting legacy, for better or worse. I've made a lot of money off of that decision, and so have many others. If they want to change that goal then thats up to the team, but that is not what this is about. This PR is purely about setting the documentation to match the travis builds. You can't say you support a version thats not being run through the test suite. :) |
|
Supporting 5.2 is a joke. And irresponsible as explained ircmaxell. As we are talking CodeIgniter and cheap hostings, 5.4 seems impractical. Yes it's EOL, but, you know... Many projects are still on 5.3 too. Similarly, 5.3.23 seems too aggressive. It's been released "only" 1 year and a half ago, and its security fixes are only for SOAP. So, I'm for 5.3, but something older than 5.3.23. |
|
Don't forget I'm nearly always right. I'm also trying to step away from political discussions and make recommendations based on other projects I've worked with in the past. We made this same investigation and decision for ZF2 and decided that 5.3.23 was right for us which is the reason I'm suggestion it here. We found that prior versions than 5.3.23 were riddled with security holes; and serious ones at that (see here http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=97802) so I think it would be largely irresponsible to promote any version younger than 5.3.23. That said, I am not involved in this project at all and I'm only giving my opinion because I've investigated this before, it's totally your call. |
|
@GeeH We’re gonna get along well. Lets leave it for the CI team to see what they think. 5.3.3 is out because it doesn’t work without a patch and I’m not gonna get involved with that. 5.3.23 would be a secure version and might hold off some of the bitching that will absolutely happen when this rolls to 5.3 and not 5.4. Still, as long as we’re not going with 5.2 at this point I’m all grins. |
|
CodeIgniter is not Symfony, going 5.3 would already be such a huge step. My primary concern is just to dig 5.2, think of the ecosystem. |
|
@philsturgeon when I say "we" I mean @weierophinney, and I always listen to @weierophinney, because he's the smartest man I know. If you're sticking on 5.2 in my mind it means you value installs over your user's security. |
|
@vlakoff when I bumped CodeIgniter from 5.1 to 5.2 I was thinking of the ecosystem. When I updated PyroCMS from 5.2 to 5.3 two years ago I was thinking of the ecosystem. I am always considering the bottom line, and quite frankly 5.2 is done with. Symfony is also trying to work out which version 3.0 should be, and its split between 5.5, 5.6 and 7.0. Seriously, 14% wanted 7.0. So, don't give me that "It's not Symfony" rubbish, because right now bumping to 5.3 is just catching up with Symfony from 2 years ago. That's fine. That is what CodeIgniter does. It trails at the back to provide support for the poor uneasy stragglers. I f**king love that. But 5.2 is done with. We know that because we can't even run tests on 5.2. The tools (which are designed to work with all reasonable versions) do not even work on 5.2. So, 5.2 is not at all an argument. Regardless of any other arguments anyone provides, the fact that the test suite does not run on 5.2 is all the reason the CI team to not say that 5.2 is supported. Run tests against it, or it's not supported. |
|
@GeeH yeah I love that guy. |
This is not a framework issue. What if someone find out some security/bug issue on PHP 5.3? Will you patch a php fix and protect your users?... I don't think so. Anywise, nobody who wants to developer a new app upon new CodeIgniter wants to write "legacy" code. User want something new... Believe in me. Centos 6.5 on Shared hosts? ....The hosts providers will attend the users as they as can. Your framework are so popular and you will not lose users because this. I guess a responsible choice is to deliver a reliable & secure solution. |
Yeh, have you heard of yum? And 7.0 is the latest centos anyway. It would be totally negligent to boot a factory version of centos 6.5. |
|
@GrahamCampbell , @yourwebmaker : I'm not defending either of that, I'm just saying that it's the current situation. Our project has a non-negligible percentage of users on PHP 5.3.3, most of who are on CentOS. Yeah, it's retarded and unsafe. I'm just the messenger here. edit: oh, "our project" in this case is not Code Igniter, or CI-based. I just came here to reply with some relevant info. |
I am kind of a new programmer and that is how I feel, I would rather rewrite things neatly using new features, but... I also need to support users. For example I made an android application for my work and Android 2.2 had like 8% usage. I had to support it. Also, if we have code to do what we need to they would be very angry if it worked and I rewrote it. So I think it is way to gray of an area to say "nobody" |
|
Are lots of non-CodeIgniter users piling in here and making generalized statements that are not relevant to the CodeIgniter community? Because I think that is whats happening. Please don't do that. |
|
I haven't used CI to develop with for a few years but my personal information is very likely to be stored in databases accessed from CI. My personal information has also been disclosed due to insecure software in the past. Hopefully my input is still valuable here. I dislike getting involved in issues like this (where flames may soon abound) but I think this is important. I'd very much like for CI to not support insecure versions of PHP. I think this should be more important to CI than the ability for developers to make money. |
|
Phil, I know what TDD is ... it's the notion of automated testing being the most important thing that I meant with that. Yes, it sucks that the lowest required version is not automatically tested. But you know what? The test suite sucks anyway. It sucked back when you merged it and it is almost untouched since you left the project because it's a PITA to work with. I too am unhappy with some of EllisLab's decisions, but you can't override them post factum when the hard work has already been done and based on them. Now you're saying that this will be another bad decision, but you know probably better than I do when exactly the decision to write code for PHP 5.2.4 was made. And that's exactly what has been done for the past few years - write code for PHP 5.2.4. Countless patches and feature requests have been rejected over that. A lot of time spent trying to make something work on 5.2 will be wasted. CodeIgniter has been called dead, irrelevant (this one by yourself), a "shit project" and whatnot, because it's not "modern" like the other 100 frameworks out there. Do I like it? Absolutely not. And I am biased, but I'm going to be extremely unhappy if this code gets released with the stamp "requires PHP 5.[3-4].x", yet it doesn't use any of the awesome features that a more recent version provides. |
Edit: Ahh I re-read your reply and see what you meant. Just wanted to be clear that I'm not on a TDD religious war, just think tests have a huge amount of value.
I am amazed to hear that tests have been ignored throughout the development progress in the two years since I left.
It's pretty common to validate what the system is doing, then check those assumptions are correct later on. Whilst that does sound awful, I would absolutely prefer to have a test suite (shitty or not) that can be improved over time, rather than flippantly just saying "yeah it probbly works" and throwing it out in front of thousands of people with its zipper undone.
Lets be fairly clear on this specific part, EllisLab didn't make any decisions about PHP version usage other than "Ok ok we'll drop PHP 4 now." is about 2010. I pushed the decision to jump to PHP 5.2 because it was absolutely time. There were enough people using it, enough distros on it, and it was fine to do so for a major version. I also made that call f**king ages ago, and made it before the test suite was merged. I am not saying you lot are wrong to continue along the goals of what 3.x was for a while, but I am saying this:
I think you've missed the point of what im getting at. "Supported version" and "Minimum version" can both be different here. You can absolutely say "This might still work on PHP 5.2, but it is not officially supported." I am saying that without tests, its not appropriately supported, and thats the whole damn point here. It's about setting expectations. If you say "It might work on 5.2 but we don't really know, do so at your own risk." then the expectations you set are in line with what you can accurately promise people. You cannot promise people your code works on 5.2, so you really should not try.
I know, I argued that very case on the last PHP Town Hall, and have written in the past that bumping versions without utilizing features is a mess, but those opinions are totally overridden when faced with the alternative: lying to a huge community of people, saying your software works on a version of PHP whilst having no idea if it does or not. That might have been acceptable in 2006-2011, but it is absolutely not acceptable now. And again, a crappy but improving over time test suite is a bazillion times better than no test suite at all. |
|
@philsturgeon I don't understand why you're getting all worked up about this. @narfbg says he wants to stay at 5.2.4 for now. If you have a problem with how unit testing/QA is done, make a pull request for that, no? I'm gonna see whether I can adjust things a bit to see whether we can get Travis to test for 5.2.4. |
|
I'm not at all worked up, I am trying to explain why saying "It works on this version" whilst not actually having a clue if it does or not is not how things need to be done in the community. If you can get the tests working on PHP 5.2 I'll be perfectly content, but that does seem like an exercise in futility when you could just merge this and tell people:
|
|
How to lose all credibility in an open source project in one pull request. |
|
How to feed the trolls... |
|
Who exactly is a troll in this instance? |
Good point. |
|
|
|
http://blog.ircmaxell.com/2014/12/being-responsible-developer.html I can see the number about unit tests effecitveness on defect detection, it is 30%. So, these test are not definitive for a claim "It supports whatever". I understand "It supports" as a promise eventually - if a bug appears there will be somebody to fix it. There is no drama. |
|
@dbernar1 I completely understand if you think I am trolling, but I'm genuinely not, it makes me feel sad when I see a credible OS project making bad decisions and losing that credibility. Granted, this isn't really the place for random opinions or observations. |
|
@GeeH Agreed. |
|
For the record, I would like to comment on @narfbg 's original close reason:
I think this is a somewhat reasonable compromise. The only reason I say somewhat is that I still believe actually advertising 5.2.* as supported is still negligent. However, if you're not willing to raise that requirement, then recommending 5.4+ is a good step in the right direction. Thank you for the consideration. |
|
@ivantcholakov If people are 30% confident about the tested versions, that's 30% better than the rest.
That is the message CodeIgniter is sending to developers. Wonderful. |
|
Related: zendframework/zendframework#7095 |
|
@Ocramius I'd like to try and avoid crossing the streams here. The arguments for bumping CI to 5.3, and to bump ZF to 5.4 are a little different. This is less about hand holding people and not letting them use a version of software thats pretty damn old now, its more about being accurate with the portrayal of which versions of PHP this software will even work on. (That said a jump to 5.4 would be nice too, but lets not try and worry about that just yet. Dropping 5.2 is much more important.) |
Agreed. I mentioned the same argument in our internal discussion.
It doesn't matter if EllisLab made the decision or if they silently agreed with yours (actually, that is one good thing that they often did). As you said, the decision was made ages ago; and the point is - job has already been done, it's too late to change it. The difference in what you and I believe this change would imply is the key - your POV affects documentation only, mine affects the codebase.
Well, "supported version" and "minimum version" are the same to me. That being said, wording can be changed. Saying something in the lines of "It should work on PHP 5.2.4, but do so on your own risk because we can't guarantee it" is fine with me (similar to how telecoms advertise maximum downloads speed, but explicitly say that they can't guarantee them). That's what recommending 5.4 means to me and I already said in my first reply that I'm all for putting more emphasis on that. The only promise that we give about 5.2 is that we will try making it work and non-optional functionality that doesn't work on 5.2 will be considered a bug. Thank you for noting that, you're the first person here not involved in the project that actually tries to see both sides of the coin. I appreciate that. |
|
@philsturgeon I actually linked it in because:
|
|
Take a look at this: https://travis-ci.org/dbernar1/CodeIgniter Looks like it might be possible to have the unit tests run on 5.2 as well. I will update you on the progress I make. |
|
@narfbg we're getting closer to the same points. :)
Leveraging PHP 5.3 functionality and saying that you will only offer active support for 5.3 and up are two totally different things. That is the crux of our difference on this view. I'm just saying you should not call it a supported version, and warn folks away from using 5.2. Security is one argument as others have said, but the fact your test suite doesn't run against it is another. You don't need to get into the nitty gritty of why in your docs, but you really can't just sit there and say "It's fine on 5.2." when you don't know that.
It sounds like 2 is being done already and that makes @ircmaxell happy. If instead of this PR you implement 1 with some wording in the docs then I'll be happier too. 3... seems like your mind is made up. |
|
@philsturgeon It doesn't make me happy. But it's a better situation than existed a few days ago. I acknowledged the step. That doesn't mean it's an end-game or an ideal. Just that it's a step in the correct direction. |
|
@dbernar1 I don't think anyone doubted it was possible, but I can already see you making changes to the test suite to rip bits out and make the tests run and that's exactly the sort of wasted effort I'm talking about. Again:
Not those exact words obviously, but that general message. Your 5.2 users are not shunned, they just have realistic exceptions, you're pushing people in the right direction softly, and if they dont bother to upgrade thats up to them. An even better message would be:
|
|
@philsturgeon It's almost done now, and very little effort was put into it. Much less effort than you've expended to write all the text you sent to this thread. As far as "making changes to tests to rip out bits", I encourage you to take another look at the diff: dbernar1@5684027 because it is just one little thing. Not anything else. It is just that quoted_printable_encode() stuff. What is that anyway? I will put that back in, it was just a temporary convenience so I can see whether there is a lot of work needed to get 5.2 testing working. Now that I know that is the only test in the whole suite that has an issue, I will go back and fix it up. |
|
OK, so this is a test that never actually ran before, since it is a test for versions lower than 5.3. I'm gonna suggest removing the part of the test that is failing in the pull request I will make for adding 5.2 unit testing support, and continue the conversation there, regarding whether that is the right approach for that particular test to avoid hijacking this thread further. |
|
@dbernar1 remember when I said "I don't think anyone doubted it was possible." I also didn't think it would be a months worth of work. I did however point out it would be an exercise in futility when you could just put a note on your documentation pointing out that using PHP 5.2 might just be a shit idea. So long as your supported version list matches up with what you are actually testing against then fine, but this outcome is much like picking the nicest looking turd in the dog park. Do as you wish. I'm out. |
|
We'll get 2 for 1 then it seems ... We'll improve the wording and @dbernar1 has the tests working on 5.2. |
A while back when I was on the team I suggested we moved from 5.1 to 5.2. This made sense two or three years ago when this branch was meant to be "out soon" but time has moved on a little bit.
When people first started grumping about 5.2 being used I explained that I didn't think it was so bad for various reasons. I know that people use CodeIgniter on versions of PHP that are WAY out of date, and I know that even 3 years ago moving from 5.1 to 5.2 pissed people off.
What has made me spin on a dime here is that the .travis.yml does not actually test against 5.2 at all, and of course it can't because vfStream has a 5.3 dependency.
On top of that, PHPUnit probably needs 5.3 too depending on the version travis is supplying you with.
SO!
If you aren't testing against 5.2, you really really cannot release with docs saying that you support 5.2. CodeIgniter was always a cowboy framework with zero tests and that is turning around. In the past were dangerous untested releases done without warning. It was a bit of a nightmare, and I had to run back from the pub one day to patch and retag a version that somebody at EllisLabs had released without warning which had some bugs on one version of PHP. Without 5.2 in the
.travis.ymlversion matrix once again I'd say you absolutely cannot say you support 5.2.Instead of trying to find a way to test on 5.2, I'd urge you just to pop up the requirements to 5.3.
This may well still work on 5.2 and the only place it will fail is if a developer tries to run
composer update, but that is only for testing, and the tests wont work anyway.I'm not going crazy here. I think PHP 5.4 would be nice, but I know that these things need to be done slowly. If you lot want to go further than carry on, but everyone else should try and avoid complaining that the level of progress is not enough.