Hi, On Sat, Aug 25, 2012 at 8:05 PM, Thomas Hruska <thru...@cubiclesoft.com>wrote:
> Good businesses plan ahead and integrate upgrade expenditures into their > cost models. ... And they also tend to avoid unnecessary costs at all costs, and that of course means they don't upgrade unless a) absolutely necessary or b) the person in charge had some free time (however they managed it) and has done an insane amount of work to ensure everything works at least as fine _after_ than _before_ the upgrade. At least for small companies. I can't imagine the workload for medium to large comanies. Is it handled per project? On Sat, Aug 25, 2012 at 6:11 PM, Lester Caine <les...@lsces.co.uk> wrote: > At the expense of adding NEW facilities for my customers. As a user and a part-time sysadmin, I completely agree with Lester's questions. They are justified, although I also agree with Rasmus that 3 years between major upgrades is way too long. I can deal with rather frequent and with minor upgrades because they don't usually break much (if anything), I just have trouble changing my hole mindset for every language/library/system/etc. every few years. While I am all for learning new things, I also like to be able to reuse my current knowledge and skills to do ever increasingly interesting things. I can not do that if I have to challenge too much too often: PHP is not the only technology I deal with. Hosting companies, sysadmins and users all need time (lots of time) to come around to relearning things they already knew how to do. Some people will rather deal with security holes than upgrade anything because that would suppose having way more tests than they have in place. Truthfully, how do you pitch upgrading? Your websites and applications run fine now. Of course you have dealt with bugs and security holes that would also be corrected with the shiny new version but *that* is my point: a new version means a potential for new bugs, while you have already dealt with them in your code. To go back to Lester's original question, I decided to forgo PHP4 completely a few years ago, and fully take the PHP5 route. I do not use any framework or library that advertises it still works on PHP4. I do not believe much in language-level optimizations, although I do make use of them. I just tend to turn to an opcode optimizer and object caching, or partial page caching, or if need be full page caching, rather than confusing my code with any DB or templating abstraction layer. Let's face it, switching from a database to another is not just about the queries in my code, we also have userland functions to think of. Also, PHP's alternate templating syntax works great, and anyway no templating engine I know can easily switch between HTML, images, PDF, XML, JSON and other media formats. I went the full framework route. Having honestly tried some of the great libraries for specific use-cases some time ago (templating, database abstraction, image generation, form handling etc., look me up if you want to know more - results might be in French and outdated), I also tried some of the then-well-known frameworks. I picked the one I liked most and I stuck with it. It has provided me with many appreciated features on top of PHP, some of which I just claimed I didn't find in independent libraries, and for many other things I picked whatever extension or library I liked most at the time of choosing. I still do a lot of things with pure PHP, mostly when I do not trust the extensions and libraries I come across. Sometimes I try a new library or extension, but I never entertained the idea of switching frameworks. Now this framework is doing the same, namely going throught beta stages to release a new major version of the framework, and I find myself with the same dilemma as with PHP 5.3+: will I upgrade? How much time will I lose re learning stuff I already knew how to do, with some improvements I won't much care about? How long before my now-older version is phased out, no longer maintained? Maybe I didn't write enough tests for the current version, but most likely they will all be useless for this new version and I will have to write them again. How is that productive? Of course, the easy answer is not to upgrade. I'd like to think PHP as a very long time support language. I'd like to think when there is backwards compatibility in userland PHP for a new version of PHP, it means the code that brought this upgrade to the language itself can be backported to older versions. A few years is a very long time for releases, but it is not very long for enterprise adoption. With PHP5.3 and 5.4 so close together in thoese terms (and far from 5.2), some might just skip 5.3 altogether and go directly 5.4 (ie. skipping the deprecation warnings and going directly for the errors). I know that's what I'll do, but at the moment I still use PHP 5.2 in production until I have time to try and debug every part of our applications on more recent versions - like that'll happen soon. The same goes for other software, MySQL and httpd to name a few. At times it feels like I don't make any progress with actual features. I guess it boils down to knowing exactly what your use cases are, being able to keep maintaining several versions of your CMS or whatever you call your system (maybe one version for each PHP version you keep track of), but still hope PHP as a language will keep track of its older versions for years, at least until many hosting companies have migrated to more recent versions. That last part assumes that hosting companies and distros drive worldwide adoption, in the sense that companies tend to act on "if everyone else does it, so should we" (not the other way around). On Sat, Aug 25, 2012 at 1:16 PM, Marco Pivetta <ocram...@gmail.com> wrote: > Just wanted to remind you that the latest Smarty 2.x version is 2.6.26, > released in the middle of 2009... > 3 years have passed by, and change is something that cannot really be > stopped. > What you say is true, versions get old. But as Lester pointed out, they work. that is why some computer systems that have been outdated for years are still functioning today. It is hard to make a case for rewriting code that already works, don't you think? Continuous integration can not help you much where major versions or backwards incompatibility are involved. On Sat, Aug 25, 2012 at 3:39 PM, Andrew Faulds <a...@ajf.me> wrote: > ISPs should have moved to 5.3 long ago. If they haven't, that isn't our > problem. I don't have any numbers on PHP adoption for versions 5.3 and forward but I will trust Lester is right in his assessment: it is not good. Why is that? Whatever the answer is, it makes your point moot: the PHP group has to care. Maybe it is a BC problem, maybe mereley an education problem, or maybe migration scripts can be written, shared and advertised to help, but either way the PHP Group is the best entity to solve the problem that is PHP Adoption. Also, Rasmus stated recently that APC is not yet ready to service PHP 5.4 on production servers. I believe PHP 5.4 is mostly compatible with PHP 5.3, so why have so few websites adopted PHP 5.4 when obviously a bunch have gone 5.3? @All To wrap up, I would like to say I really like the new propose/discuss/vote/commit process. an RFC on the wiki, coupled with a call for comments on the mailing list and finally a vote are much easier to follow than the old offline, IRC or hard-to-track mailing list discussions for those of us non-core-developers who try to keep up with this list. That has been a really great improvement. It is not always easy, and sometines I miss something, but it helps me a lot to keep up. However, I noticed in the ChangeLog that not all entries relate to a bug report. Maybe that could be amended to link to the RFC when available, or maybe a bug report could be created when the code is pushed/committed to reflect the changes so that the ChangeLog can point to a copy of the RFC so people can find relevant information more easily? That would help promote big changes (as in "make them noticeable in all the clutter"), as well as help educate users about why they were introduced and how they can be used, and also help mitigate documentation shortcomings, while requiring little time on the part of the maintainer. I do think education is the key to many things in our world. Please do not rely purely on the blogosphere to spread the word. Best regards, -- Guillaume Rossolini
