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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
