Re: [SMARTY-DEV] clear_compiled_tpl() bug or missing feature

--- Monte Ohrt <monte@ispi.net> wrote: > Maybe all the cache and compile files could be under a version-named > subdirectory. That would keep things separate and easy to maintain. > > templates_c/2.6.0-RC1/ > templates_c/2.6.0-RC2/ > templates_c/2.6.0/ boo! I already do this as part of my application control. Except I do it like this: tmp/site_name/smarty_ver_num/compiled tmp/site_name/smarty_ver_num/cached You may not like that, and I may not like your decisions. I think it is a boon that Smarty doesn't force us down one path or another. Indeed, I don't much see the point of including this in Smarty, to be honest. After all, only *one* version is expected to be used for a given install, yes? Sure, upgrading requires a modicum of work--but you can always script it or include it in your framework. I'd rather that admin chores were kept as such lest Smarty try to do what it can not. By-the-way, I can hardly see how the general idea of version checking can be done without a performance impact. Further, "better versioning" as suggested is not really the solution, IMHO. Bharat mentioned that he was using a CVS copy of smarty. By definition, that is unreleased. There is no way to know what code works with what. Do all the plugins work that specific copy of the Smarty class you got from CVS? Really, the only way to get finer detail is to do more *releases* and that's a different kettle of fish :) All-in-all, if an efficient method is found I'm not against it, but if it is only protecting CVS cases (ie. distributions of Smarty code from CVS, not release) then I think it does not merit consideration. Just my 2c! xo boots __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree