One more thought on this subject, why not add 'minimum php version' to the .info file, and show modules that require php5 as disabled on the modules list if php5 isn't available. This would be a fairly simple thing that could still be slipped into 6.x that would allow us to start creating contrib modules that require php5 and get users thinking about the advantages of php5 so they start putting pressure on hosts to upgrade. Native timezone support didn't start working until 5.2, for instance, so the version check should test both major and minor version numbers. And add php version info to the module download page, too. Karen
+1 on this as a gentle first step that can be implemented now and help us through the process in the future no matter what the time scale of the conversion to requiring 5 is. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Karen Stevenson Sent: Tuesday, June 26, 2007 8:20 AM To: development@drupal.org Subject: Re: [development] Go PHP 5, Go! One more thought on this subject, why not add 'minimum php version' to the .info file, and show modules that require php5 as disabled on the modules list if php5 isn't available. This would be a fairly simple thing that could still be slipped into 6.x that would allow us to start creating contrib modules that require php5 and get users thinking about the advantages of php5 so they start putting pressure on hosts to upgrade. Native timezone support didn't start working until 5.2, for instance, so the version check should test both major and minor version numbers. And add php version info to the module download page, too. Karen -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.9.9/870 - Release Date: 6/26/2007 10:07 AM
On Jun 26, 2007, at 5:20 AM, Karen Stevenson wrote:
why not add 'minimum php version' to the .info file, and show modules that require php5 as disabled on the modules list if php5 isn't available. This would be a fairly simple thing that could still be slipped into 6.x that would allow us to start creating contrib modules that require php5 and get users thinking about the advantages of php5 so they start putting pressure on hosts to upgrade.
People interested in this should see my patch for D6 (which thankfully already landed) to do the same with a "core" attribute in the .info file to prevent D6 core from enabling D5 modules: http://drupal.org/node/146910 You could probably re-use much of the same code/UI/logic from that patch. On to the bigger question: - Once D7 is about to be released and we have actual facts about php5 availability for our user base (not speculation like "70% of our users will be left behind"), we can very publicly announce that we're going to extend the support life-cycle of D6 core, and encourage module maintainers to do the same. Killes suggested this originally, and it's clearly a great idea. - We have a ton of tools now to make this extended support good (release system, extra branches for older versions of core, update_status, etc). If anything, giving D6 a little more time to live will be a good thing, and will leave less of our users behind than our current frenzied release cycles (which are great for us developers, don't get me wrong -- +1 on the drop always moving). - The Drupal project continuing to support D6 until it's "safe" to completely drop php4 is much less destructive for us than Drupal core continuing to support php4 indefinitely. Cheers, -Derek (dww)
Hi, I definitely support the proposal of extending support for D6, if necessary, while new features and improvements can continue on a PHP5 branch. what would be nifty is if the drupal_notify() function collected info about the php version (along with drupal version) and sent it back to drupal.org for analysis, so migration of the drupal user base towards PHP5 could be tracked (would be nice to track db type and version as well) --mark On 6/26/07, Derek Wright <drupal@dwwright.net> wrote:
On Jun 26, 2007, at 5:20 AM, Karen Stevenson wrote:
why not add 'minimum php version' to the .info file, and show modules that require php5 as disabled on the modules list if php5 isn't available. This would be a fairly simple thing that could still be slipped into 6.x that would allow us to start creating contrib modules that require php5 and get users thinking about the advantages of php5 so they start putting pressure on hosts to upgrade.
People interested in this should see my patch for D6 (which thankfully already landed) to do the same with a "core" attribute in the .info file to prevent D6 core from enabling D5 modules:
You could probably re-use much of the same code/UI/logic from that patch.
On to the bigger question:
- Once D7 is about to be released and we have actual facts about php5 availability for our user base (not speculation like "70% of our users will be left behind"), we can very publicly announce that we're going to extend the support life-cycle of D6 core, and encourage module maintainers to do the same. Killes suggested this originally, and it's clearly a great idea.
- We have a ton of tools now to make this extended support good (release system, extra branches for older versions of core, update_status, etc). If anything, giving D6 a little more time to live will be a good thing, and will leave less of our users behind than our current frenzied release cycles (which are great for us developers, don't get me wrong -- +1 on the drop always moving).
- The Drupal project continuing to support D6 until it's "safe" to completely drop php4 is much less destructive for us than Drupal core continuing to support php4 indefinitely.
Cheers, -Derek (dww)
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
On Tue, 2007-06-26 at 10:13 -0700, Derek Wright wrote:
On to the bigger question:
- Once D7 is about to be released and we have actual facts about php5 availability for our user base (not speculation like "70% of our users will be left behind"), we can very publicly announce that we're going to extend the support life-cycle of D6 core, and encourage module maintainers to do the same. Killes suggested this originally, and it's clearly a great idea.
Cheers, -Derek (dww)
I think Ubuntu's model of doing a long term support release may be nice for drupal, but it's asking a lot of the community, and who ever has the maintainer role for a particular version.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Darrel O'Pry schrieb:
On Tue, 2007-06-26 at 10:13 -0700, Derek Wright wrote:
On to the bigger question:
- Once D7 is about to be released and we have actual facts about php5 availability for our user base (not speculation like "70% of our users will be left behind"), we can very publicly announce that we're going to extend the support life-cycle of D6 core, and encourage module maintainers to do the same. Killes suggested this originally, and it's clearly a great idea.
Cheers, -Derek (dww)
I think Ubuntu's model of doing a long term support release may be nice for drupal, but it's asking a lot of the community, and who ever has the maintainer role for a particular version.
Well, if you get Mark Shuttleworth to sponsor that I'll happily release Drupal 4.7.42 in 2023. ;) One more serious note: The Ubuntu model doesn't make sense for Drupal. Ubuntu is doing ths in order to get a higher industry adaption for their Linux distribution. Industry apparently likes to not have software every few years. However, Drupal is mainly used for Websites. Websites that show to the world how fashionable, geeky, modern, etc the company that has them is. For this reason, websites get refurbished every two years or so. Matches excellent to Drupal's release cycle if you only update every second release. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGjBlOfg6TFvELooQRAh6oAJ46mUl5MIglhprmhUuJP1Jy7YDAAACgvGmr 787UDPjLNNo5E6keHB3mkjc= =FjZt -----END PGP SIGNATURE-----
More precisely, industry is mostly locked on the yearly period, notably for budgeting considerations, hence once-a-year or once-every-other-year releases, and multi-year support plans for enterprise-bound software, instead of several-times-a-year. So, if indeed we resumed a once-a-year schedule, updating every second release would make sense. ----- Original Message ----- From: "Gerhard Killesreiter" <gerhard@killesreiter.de> To: <development@drupal.org> Sent: Thursday, July 05, 2007 12:03 AM Subject: Re: [development] Go PHP 5, Go! [...]
Ubuntu is doing ths in order to get a higher industry adaption for their Linux distribution. Industry apparently likes to not have software every few years.
However, Drupal is mainly used for Websites. Websites that show to the world how fashionable, geeky, modern, etc the company that has them is. For this reason, websites get refurbished every two years or so. Matches excellent to Drupal's release cycle if you only update every second release. [...]
On Jul 4, 2007, at 5:49 PM, Darrel O'Pry wrote:
and who ever has the maintainer role for a particular version.
If the Drupal project considered an extended lifetime for D6 to be of strategic importance, nothing stops us from appointing a co- maintainer. It doesn't have to only be Gabor forever -- that's just our current convention. Again, let's decide when it matters. For now, we're just brainstorming our (many) options that don't involve tying ourselves to PHP4 indefinitely. Cheers, -Derek (dww)
participants (9)
-
Aaron Winborn -
Caleb Gilbert -
Darrel O'Pry -
Derek Wright -
FGM -
Gerhard Killesreiter -
Karen Stevenson -
mark burdett -
Walt Daniels