On 25/08/12 13:08, Lester Caine wrote:
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
