Seems to me then that adding the aforementioned required php version info to a module's info file (assuming php4 if not set and graying out the module in admin if that php version is not installed) would be the way to go. This would allow contributed modules to decide for themselves whether to support php4, 5, or even 6, and pushes along evolution a little more smoothly and organically.

Any chance something like this could be implemented in time for the code freeze? It could piggy-back on the recent 'core' info patch. Might allow for some early adopters.

Aaron

Caleb Gilbert wrote:

In considering where to draw the line on PHP4 vs PHP5, isn't erring (slightly) on the side of 'early adoption' much better for Drupal's brand than erring on the side of 'falling behind the technology curve'....especially considering that the strength of Drupal's brand primarily *is* that of being a CMS-whatcha'm-thingy for advanced users/developers?

There is more than this version migration to consider - PHP6 is actually nearing release after all. While this may seem like an annoying thing to consider since PHP5 and Drupal hasn't even been settled yet - history of online technology would seem to suggest that if CMS's/web-frame-work's/whatever's which is currently built upon PHP snoozes, it may be leaving itself open to having someone (or in this case, another open source project) raise the technological bar on them overnight.

For those who haven't seen the features of PHP6 yet - http://www.corephp.co.uk/archives/19-Prepare-for-PHP-6.html (e.g., integrated APC, always-on FastCGI, and more) - it's seems well worth plotting a course to get there as soon as *reasonably* possible (even if that is a couple/few years from now).

- Caleb
http://highervisibilitywebsites.com