Many of my 'problems' with all of the 'progress' being made with PHP are caused
because I'm using a core framework who's origins go back to PHP4 days. Many of
the facilities are currently unusable simply because they have not had any of
the PHP5.2/3/4 changes applied while all the stuff that is still being used
actively on live (paying) sites have been updated even to be E_STRICT compliant.
ADOdb has provided me with an ideal base for many years, and the data processing
systems have been fine tuned over many years with PDO actually being more of a
hindrance to performance than an improvement. The reason for that being that the
generic data structures developed for generic drivers are at odds with the PDO
'style' and so extra conversions can be needed so the generic drivers are used.
I'm still on Smarty2 as the templating system as switching to Smarty3 will
require another long conversion process, and we are up to speed with what S2 can
do - and it works.
All of this is working on a base which allows a sites whole style to be
remodelled simply from the css theme and we can add modules easily ( reusing the
core system code ). I can 'copy' an existing 'static' site and enhance it with
on-line editing and other interactive facilities in a few hours while
maintaining the same style that the owner is used to, and this is what we are
doing with many of the older sites we have taken over support for.
The main problem here is that the likes of the Zend framework and other
'controller based' systems seem to be way people want to see PHP develop, so
keeping 'older' style systems working is getting more and more difficult.
The question ... how many other people are fighting the same up hill struggle?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2012.08.25. 11:16, "Lester Caine" lester@lsces.co.uk ezt írta:
Many of my 'problems' with all of the 'progress' being made with PHP are
caused because I'm using a core framework who's origins go back to PHP4
days. Many of the facilities are currently unusable simply because they
have not had any of the PHP5.2/3/4 changes applied while all the stuff that
is still being used actively on live (paying) sites have been updated even
to beE_STRICTcompliant.ADOdb has provided me with an ideal base for many years, and the data
processing systems have been fine tuned over many years with PDO actually
being more of a hindrance to performance than an improvement. The reason
for that being that the generic data structures developed for generic
drivers are at odds with the PDO 'style' and so extra conversions can be
needed so the generic drivers are used.I'm still on Smarty2 as the templating system as switching to Smarty3
will require another long conversion process, and we are up to speed with
what S2 can do - and it works.All of this is working on a base which allows a sites whole style to be
remodelled simply from the css theme and we can add modules easily (
reusing the core system code ). I can 'copy' an existing 'static' site and
enhance it with on-line editing and other interactive facilities in a few
hours while maintaining the same style that the owner is used to, and this
is what we are doing with many of the older sites we have taken over
support for.The main problem here is that the likes of the Zend framework and other
'controller based' systems seem to be way people want to see PHP develop,
so keeping 'older' style systems working is getting more and more difficult.The question ... how many other people are fighting the same up hill
struggle?--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
So what do you propose?
There always will be people who don't want any new fearure or improvement
but their code workinf forever without any investment(refactoring) on their
part.
We shouldn't stop the development for that alone.
If I were them, I would pick an enterprise distro like rhel, where I can
get just that: same php version for many years with support.
Heya,
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. You can either freeze the environment and plan to re-build your
projects or maintain them, applying change as it comes, or maintain the
older software in-house (you will end up with something really hard to
manage).
I can suggest you (at least it works for me) to use a continuous
integration environment/server and run your sites with a dependency manager
like composer (or something like an svn:external to a "latest" branch of
the dependencies). Running the "composer update" command, the version of
the software used by my projects gets automatically bumped to the latest
available one, and then the CI environment runs the tests. That doesn't
ensure that 100% of everything will work, but reduces the efforts needed to
keep up with changes. This doesn't apply to major version changes like
Smarty 2.x -> Smarty 3.x, obviously, but I hope it helps in reducing your
workload while encouraging change and making it smoother.
As said by Ferenc, you cannot think of avoiding refactoring (at least
without freezing the project), that's part of our job.
Marco Pivetta
2012.08.25. 11:16, "Lester Caine" lester@lsces.co.uk ezt írta:
Many of my 'problems' with all of the 'progress' being made with PHP are
caused because I'm using a core framework who's origins go back to PHP4
days. Many of the facilities are currently unusable simply because they
have not had any of the PHP5.2/3/4 changes applied while all the stuff that
is still being used actively on live (paying) sites have been updated even
to beE_STRICTcompliant.ADOdb has provided me with an ideal base for many years, and the data
processing systems have been fine tuned over many years with PDO actually
being more of a hindrance to performance than an improvement. The reason
for that being that the generic data structures developed for generic
drivers are at odds with the PDO 'style' and so extra conversions can be
needed so the generic drivers are used.I'm still on Smarty2 as the templating system as switching to Smarty3
will require another long conversion process, and we are up to speed with
what S2 can do - and it works.All of this is working on a base which allows a sites whole style to be
remodelled simply from the css theme and we can add modules easily (
reusing the core system code ). I can 'copy' an existing 'static' site and
enhance it with on-line editing and other interactive facilities in a few
hours while maintaining the same style that the owner is used to, and this
is what we are doing with many of the older sites we have taken over
support for.The main problem here is that the likes of the Zend framework and other
'controller based' systems seem to be way people want to see PHP develop,
so keeping 'older' style systems working is getting more and more
difficult.The question ... how many other people are fighting the same up hill
struggle?--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
So what do you propose?
There always will be people who don't want any new fearure or improvement
but their code workinf forever without any investment(refactoring) on their
part.
We shouldn't stop the development for that alone.
If I were them, I would pick an enterprise distro like rhel, where I can
get just that: same php version for many years with support.
Marco Pivetta wrote:
Just wanted to remind you that the latest Smarty 2.x version is 2.6.26, released
in the middle of 2009...
And our own version of Smarty2 has been maintained and updated several times in
the intervening period. It's a lot easier to fix security holes as they are
identified than going through several thousand templates and updating them. But
more difficult here is a change that Smarty3 made which would require rewriting
the whole way some processes work in the framework :(
DO we spend time rewriting everything again, or use what we have working and
carry on developing new facilities on that?
3 years have passed by, and change is something that cannot really be stopped.
You can either freeze the environment and plan to re-build your projects or
maintain them, applying change as it comes, or maintain the older software
in-house (you will end up with something really hard to manage).
I can suggest you (at least it works for me) to use a continuous integration
environment/server and run your sites with a dependency manager like composer
(or something like an svn:external to a "latest" branch of the dependencies).
Running the "composer update" command, the version of the software used by my
projects gets automatically bumped to the latest available one, and then the CI
environment runs the tests. That doesn't ensure that 100% of everything will
work, but reduces the efforts needed to keep up with changes. This doesn't apply
to major version changes like Smarty 2.x -> Smarty 3.x, obviously, but I hope it
helps in reducing your workload while encouraging change and making it smoother.
As said by Ferenc, you cannot think of avoiding refactoring (at least without
freezing the project), that's part of our job.
How about major versions changes like PHP5.2-3-4 in some ways they are as bad as
the Smarty changes. I still feel that while 'incremental' changes have little
effect on BC, the overall set of changes from 5.2 to 5.4 and now going on to 5.5
has resulted in a lot more areas that need to be tidied up and often re-writen
in sites that were probably developed in PHP5.0 but work fine in 5.2. The vast
majority of users have not yet updated to 5.3, simply because their ISP's
haven't, and now we have 5.4 which ASSUMES that sites have been updated. We will
warn in 5.3 and remove in 5.4 only works if you do roll forward every time :(
Personally I'd avoided e_strict while I waited for some clean examples of how
the code should be done to appear ... they still haven't and PHP5.4 came out and
all the e_strict warnings became a problem. Run a current joomla site on a stock
5.4 install ... it's unusable until you disable all the new stuff. It took me a
couple of days to get that customers sites moved over and running again ... some
still are only holding pages ... now I need to find out why the remaining ones
don't work on PHP5.4 ... more work that I don't have time for :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Marco Pivetta wrote:
Just wanted to remind you that the latest Smarty 2.x version is
2.6.26, released
in the middle of 2009...
And our own version of Smarty2 has been maintained and updated several
times in the intervening period. It's a lot easier to fix security
holes as they are identified than going through several thousand
templates and updating them. But more difficult here is a change that
Smarty3 made which would require rewriting the whole way some
processes work in the framework :(
DO we spend time rewriting everything again, or use what we have
working and carry on developing new facilities on that?3 years have passed by, and change is something that cannot really be
stopped.
You can either freeze the environment and plan to re-build your
projects or
maintain them, applying change as it comes, or maintain the older
software
in-house (you will end up with something really hard to manage).
I can suggest you (at least it works for me) to use a continuous
integration
environment/server and run your sites with a dependency manager like
composer
(or something like an svn:external to a "latest" branch of the
dependencies).
Running the "composer update" command, the version of the software
used by my
projects gets automatically bumped to the latest available one, and
then the CI
environment runs the tests. That doesn't ensure that 100% of
everything will
work, but reduces the efforts needed to keep up with changes. This
doesn't apply
to major version changes like Smarty 2.x -> Smarty 3.x, obviously,
but I hope it
helps in reducing your workload while encouraging change and making
it smoother.
As said by Ferenc, you cannot think of avoiding refactoring (at least
without
freezing the project), that's part of our job.How about major versions changes like PHP5.2-3-4 in some ways they are
as bad as the Smarty changes. I still feel that while 'incremental'
changes have little effect on BC, the overall set of changes from 5.2
to 5.4 and now going on to 5.5 has resulted in a lot more areas that
need to be tidied up and often re-writen in sites that were probably
developed in PHP5.0 but work fine in 5.2. The vast majority of users
have not yet updated to 5.3, simply because their ISP's haven't, and
now we have 5.4 which ASSUMES that sites have been updated. We will
warn in 5.3 and remove in 5.4 only works if you do roll forward every
time :(Personally I'd avoided e_strict while I waited for some clean examples
of how the code should be done to appear ... they still haven't and
PHP5.4 came out and all the e_strict warnings became a problem. Run a
current joomla site on a stock 5.4 install ... it's unusable until you
disable all the new stuff. It took me a couple of days to get that
customers sites moved over and running again ... some still are only
holding pages ... now I need to find out why the remaining ones don't
work on PHP5.4 ... more work that I don't have time for :(
OK Lester, you've whined enough, what do you want us to do? Freeze
development for 5 years so ISPs can slowly catch up, or something?
--
Andrew Faulds
http://ajf.me/
Andrew Faulds wrote:
OK Lester, you've whined enough, what do you want us to do? Freeze development
for 5 years so ISPs can slowly catch up, or something?
Simply taking care to provide fixed point that we can work to would have helped.
LTS versions have been rejected in the past, but PLEASE can we stop producing
yet another PHP5.x version and make PHP5.4 an end point that we can work to and
produce comprehensive upgrade notes to help people get to that point. Make that
an LTS version and move new development over to PHP6 where there would be more
'flexibility' to break things if needs be.
PHP5.2 is the current LTS almost by default, but one thing that we need to try
and do is get the user community to move to PHP5.4 rather than the current move
to PHP5.3 on many ISP's ( at least the one's I'm having to deal with ). If
PHP5.4 is ring fenced then at least we have a point to aim for? Currently the
situation on the ground is that PHP5.3 is the next production version for ISP's
despite the fact that it's not supported!
I was reconsidering a point I made earlier, and all that we need is a 'legacy'
php.ini that would provide a cleaner base for ISP's moving from PHP5.2 and also
a reference point so we can document changes needed to the older code to bring
it up to date ... strict compliant without any deprecated warnings. A 'matching'
php.ini for PHP5.3 would help things in the interim. Having to manage sites on
PHP5.2 and 5.3, while testing the same sites on 5.4 is my current situation, and
having PHP5.5 looming in the background is just another irritation.
I have no doubt that it will take some years for PHP5.4 to replace 5.2, but at
least we will have a fixed target to work with?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Andrew Faulds wrote:
OK Lester, you've whined enough, what do you want us to do? Freeze
development
for 5 years so ISPs can slowly catch up, or something?Simply taking care to provide fixed point that we can work to would
have helped. LTS versions have been rejected in the past, but PLEASE
can we stop producing yet another PHP5.x version and make PHP5.4 an
end point that we can work to and produce comprehensive upgrade notes
to help people get to that point. Make that an LTS version and move
new development over to PHP6 where there would be more 'flexibility'
to break things if needs be.PHP5.2 is the current LTS almost by default, but one thing that we
need to try and do is get the user community to move to PHP5.4 rather
than the current move to PHP5.3 on many ISP's ( at least the one's I'm
having to deal with ). If PHP5.4 is ring fenced then at least we have
a point to aim for? Currently the situation on the ground is that
PHP5.3 is the next production version for ISP's despite the fact that
it's not supported!
What? PHP 5.2 is no longer updated. PHP 5.3 is the current LTS, people
are just being too slow to upgrade.
I was reconsidering a point I made earlier, and all that we need is a
'legacy' php.ini that would provide a cleaner base for ISP's moving
from PHP5.2 and also a reference point so we can document changes
needed to the older code to bring it up to date ... strict compliant
without any deprecated warnings. A 'matching' php.ini for PHP5.3 would
help things in the interim. Having to manage sites on PHP5.2 and 5.3,
while testing the same sites on 5.4 is my current situation, and
having PHP5.5 looming in the background is just another irritation.
ISPs should have moved to 5.3 long ago. If they haven't, that isn't our
problem.
I have no doubt that it will take some years for PHP5.4 to replace
5.2, but at least we will have a fixed target to work with?
--
Andrew Faulds
http://ajf.me/
Andrew Faulds wrote:
ISPs should have moved to 5.3 long ago. If they haven't, that isn't our problem.
I'll just refer you to
http://w3techs.com/technologies/details/pl-php/5/all
5.3 is NOT being used because of the changes it introduced, and distributions do
NOT yet include 5.4 as the norm
Personally I have to live with real life, and just want to help change that
situation.
If you can't be bothered to help then just stand back!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Andrew Faulds wrote:
ISPs should have moved to 5.3 long ago. If they haven't, that isn't
our problem.
I'll just refer you to
http://w3techs.com/technologies/details/pl-php/5/all
5.3 is NOT being used because of the changes it introduced, and
distributions do NOT yet include 5.4 as the norm
So what on earth are we supposed to do? Say "oh sorry lol we'll start
supporting 5.2 again!" or something?
Personally I have to live with real life, and just want to help change
that situation.
Me too. My code relies on out-of-date extensions and PHP features, which
is why I'm refactoring and rewriting the parts which do.
If you can't be bothered to help then just stand back!
Oh I'd love to help, Lester, but ISP issues are not the PHP group's job.
--
Andrew Faulds
http://ajf.me/
Andrew Faulds wrote:
Personally I have to live with real life, and just want to help change that
situation.
Me too. My code relies on out-of-date extensions and PHP features, which is why
I'm refactoring and rewriting the parts which do.
Exactly what I've been doing for the last year ... INCLUDING PEAR
At the expense of adding NEW facilities for my customers.
But with the goal posts continuing to be moved forward, it would be nice to have
a goal to aim at? Which is why I'm asking for one ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Andrew Faulds wrote:
Personally I have to live with real life, and just want to help
change that
situation.
Me too. My code relies on out-of-date extensions and PHP features,
which is why
I'm refactoring and rewriting the parts which do.Exactly what I've been doing for the last year ... INCLUDING PEAR
At the expense of adding NEW facilities for my customers.
But with the goal posts continuing to be moved forward, it would be nice
to have a goal to aim at? Which is why I'm asking for one ...
Well, there won't be one. If anything we are trying to move faster. More
frequent smaller releases is the goal. The 3 years between 5.2 and 5.3
was way too long.
-Rasmus
Rasmus Lerdorf wrote:
Andrew Faulds wrote:
Personally I have to live with real life, and just want to help
change that
situation.
Me too. My code relies on out-of-date extensions and PHP features,
which is why
I'mrefactoring andrewriting the parts which do.Exactly what I've been doing for the last year ... INCLUDING PEAR
At the expense of adding NEW facilities for my customers.
But with the goal posts continuing to be moved forward, it would be nice
to have a goal to aim at? Which is why I'm asking for one ...
Well, there won't be one. If anything we are trying to move faster. More
frequent smaller releases is the goal. The 3 years between 5.2 and 5.3
was way too long.
So why is moving all new work to PHP6 and introducing a freeze on PHP5.4 such a
problem? In hindsight PHP5.4 SHOULD have been PHP6. We also need to be able to
have stability that we can aim for in production.
Loading up a new set of rework requirements to often just means that previous
work never gets finished :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Rasmus Lerdorf wrote:
Andrew Faulds wrote:
Personally I have to live with real life, and just want to help
change that
situation.
Me too. My code relies on out-of-date extensions and PHP features,
which is why
I'mrefactoring andrewriting the parts which do.Exactly what I've been doing for the last year ... INCLUDING PEAR
At the expense of adding NEW facilities for my customers.
But with the goal posts continuing to be moved forward, it would be
nice
to have a goal to aim at? Which is why I'm asking for one ...
Well, there won't be one. If anything we are trying to move faster. More
frequent smaller releases is the goal. The 3 years between 5.2 and 5.3
was way too long.So why is moving all new work to PHP6 and introducing a freeze on PHP5.4
such a problem? In hindsight PHP5.4 SHOULD have been PHP6. We also need
to be able to have stability that we can aim for in production.
Loading up a new set of rework requirements to often just means that
previous work never gets finished :(
Those are just numbers and 5.4 is already frozen. We are only fixing
bugs in it.
-Rasmus
Andrew Faulds wrote:
Personally I have to live with real life, and just want to help
change that
situation.
Me too. My code relies on out-of-date extensions and PHP features,
which is why
I'm refactoring and rewriting the parts which do.Exactly what I've been doing for the last year ... INCLUDING PEAR
At the expense of adding NEW facilities for my customers.
But with the goal posts continuing to be moved forward, it would be nice
to have a goal to aim at? Which is why I'm asking for one ...
Nothing is stopping you from forking some flavor of PHP for those who
are like you. PHP is on GitHub now, which makes it a lot easier to do
change management and you can easily integrate whatever you like and
don't like into your own fork from the main branch. Make your own goal
post. I'm sure the PHP developers here would be more than happy to let
you manage an official LTS version if it meant you would stop
complaining on this list. I'm sure web hosts would love your LTS
version because they hate upgrades because upgrading costs time and
money. Good businesses plan ahead and integrate upgrade expenditures
into their cost models.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
Dear Lester,
Please learn Ruby.
Thank You,
Everyone
Hi,
On Sat, Aug 25, 2012 at 8:05 PM, Thomas Hruska thruska@cubiclesoft.comwrote:
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?
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).
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.
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
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?
Actually, no. In fact, if anything, I think it's just the opposite: it's hard to make a case for letting code stagnate. No matter how stable an app may seem, there will come a day when it will suffer a serious blow. It might be that a critical component has a major security breach, or a business requirement comes along that forces you to play nice with another system in such a way that it can only be done with newer software, or the underlying hardware breaks and cannot be replaced, or the company grows and the app can no longer scale... whatever. The world changes, and it's going to take your app with it one way or the other.
The term is technical debt, and like financial debt, you must deal with it, you must keep ahead of it. If you're pouring all your resources into new code, then you're piling up technical debt.
Yes, refactoring code to modernize it isn't always fun, but if you do it regularly, then the debt remains low and you settle in making making many small changes at a constant pace and over time, rather than making big changes too quickly. Other benefits come from regularly revisiting code, too, e.g., fixing hidden bugs, increasing performance, reworking algorithms and flows with the benefit of experience and hindsight, etc.
How much maintenance, as a share of overall work, is right for an app varies with the overall quality of the code and how rapidly the app is evolving. It may be 20% or 80%, you have to decide for yourself. But if all you're doing is adding code without ever refactoring code, you're setting yourself up for a real mess when the sh** hits the fan, and you're doing your company (or customers, or clients) a terrible disservice.
BTW, before you blow this off as an unrealistic view, consider my own situation. A few years ago, I took over management of a few million lines of code that had largely come to be via the throw it together and never touch it again method. Most of it was written in the PHP 4 era (some in the PHP 3 era), and it had things like reliances on pre-1.0 beta releases of pear libraries that had long since lived a full life and died in unmaintained peace. These were mission critical applications, so we couldn't just toss them out or stop new development. At the same time, they were starting to become problematic, with serious performance issues and security flaws.
Our approach was simple: whenever we added anything, we took the time do it the right way, which almost always included refactoring old code that was involved. And, we spent most of our time fixing things, pulling dependencies on third-party libraries (like pear), and so forth. Over time, things have improved dramatically, and now most of that old code at least runs under 5.3 comfortably. Our newest apps specifically target 5.3 and will be switched to 5.4 as soon as Zend gets its act together and releases Zend Server with 5.4. Perhaps most interesting, the business users are really starting to understand the importance of staying on top of technical debt, since they were bit so badly by not doing so and are now starting to reap the benefits of doing so.
My point is, I feel your pain. But you have to power through that, get the code cleaned up, and then get it on a maintenance schedule that keeps it that way. The rest of the world is not going to slow down for you, so stop waiting for that to happen and just jump in.
Regards,
Bob
Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).
Guillaume Rossolini wrote:
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.
Thanks for the comments Guillaume ... it's nice to here that I am not totally
out on my own ;)
Personally as I have said before I came in just prior to PHP5 and so all my
production work has always been on PHP5, but at that time I was porting tikiwiki
to support Firebird, and then forking from that simply because their methods did
not allow for a modular approach. That HAD to support the existing user base and
PHP4 and it was some time before PHP5 only builds were adopted - actually on
PHP5.2 :) Maintaining an open access to any database was just a natural
requirement that I think 'tiki' itself has now lost but which we try to
maintain. I simply can't understand how people cope with MySQL without an online
backup system but that is another debate.
I was hoping that I could make PHP5.4/e_strict another fixed point, but I've
already hit a problem that can't simply be worked around, so when running the
e-commerce package e_strict and e_notice have to be switched off :( Reworking
the entire translation system so that it does not redefine defines is just too
much work at the moment, and other areas need major work to prevent other
messages. The shops work and have a LOT of content, so reworking will be
necessary, but it does not produce any financial advantage to do it at the
moment! I'd avoided touching them up until now as they ARE working reliably. The
plan WAS to make the next major release PHP5.4/e_strict compliant, but that's
not going to happen now. We will just have to define a php.ini configuration
that is required for both PHP5.3 and PHP5.4 to make things work.
Robert ... The main problem with the PHP5.3/4 changes are that the attitude with
PHP5.3 was 'you don't have to worry', but very quickly that became 'now you do'
simply by the switch of the default on e_strict. Perhaps when every existing
project is totally e_strict complaint things can be different, but the amount of
work needed to be carried out is simply not being achieved, so we have to decide
if we want to spend time fixing things like PEAR - my own patches for which I've
recently published - or simply switch off the problem and disable e_strict? I
know I've been banging on about this for a long time - but I'm still trying to
update my own and other peoples code to work cleanly today :( It would be nice
to see a few more people helping ... rather than simply complaining at my
moaning ... PHP created the problems 'full stop'
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
..snip
Robert ... The main problem with the PHP5.3/4 changes are that the attitude
with PHP5.3 was 'you don't have to worry', but very quickly that became 'now
you do' simply by the switch of the default on e_strict. Perhaps when every
existing project is totally e_strict complaint things can be different, but
the amount of work needed to be carried out is simply not being achieved, so
we have to decide if we want to spend time fixing things like PEAR - my own
patches for which I've recently published - or simply switch off the problem
and disable e_strict? I know I've been banging on about this for a long time
- but I'm still trying to update my own and other peoples code to work
cleanly today :( It would be nice to see a few more people helping ...
rather than simply complaining at my moaning ... PHP created the problems
'full stop'
Ok, I believe your views have been expressed clearly and for the
sanity of the mailing-list I'd consider stopping this thread.
I would however suggest that you create an RFC which outlines exactly
what you'd like to change and how you'd like to see it change and from
there, a vote will ensue.
--
David Coallier
Ferenc Kovacs wrote:
So what do you propose?
There always will be people who don't want any new fearure or improvement but
their code workinf forever without any investment(refactoring) on their part.
We shouldn't stop the development for that alone.
If I were them, I would pick an enterprise distro like rhel, where I can get
just that: same php version for many years with support.
The problem is that non one is supporting a LTS version of PHP5.2? And that is
what is needed even to support the like of Joomla where I've had to switch off
e_strict and e_warnings just to get it to run on the PHP5.4 servers.
I'm not proposing anything, I'm asking if other people are having the same
problem to find out what DOES need to be done. PHP5.2 IS still the mainstay of
hosted services, and unfortunately the shit is hitting the fan when ISP's switch
even to PHP5.3 simply because the bulk of sites are not updated everytime PHP
changes something.
What I would like to see is a sensible discussion on supporting the vast
majority of users with the problems they will have in simply catching up. ISP's
need to be educated as to settings that while not 'preferred' for modern
developments, are necessary simply to keep existing sites running. I could even
make a case for a 'legacy' build of PHP5.4 which will actually run existing
sites out of the box, which ISP's could then adopt without the risk of breaking
the vast majority of their customers sites.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Many of my 'problems' with all of the 'progress' being made with PHP are caused because I'm using a core framework who's origins go back to PHP4 days.
I'm sorry, but what is the point of this email? This is a mailing list, not a group therapy session for people who didn't update their code regularly.
David