[development] Go PHP 5, Go!

Larry Garfield larry at garfieldtech.com
Tue Jun 26 21:47:39 UTC 2007


The "organized boycott of php4-only hosts" is a somewhat harsh phrasing for what the GoPHP5 effort is trying to do: Get a lot of projects together to say "we're done with PHP 4 now, thank you" at the same time, and give hosts fair warning of that so they can upgrade.  Even though the target date for GoPHP5 is February of next year, most projects won't have an actual release until later in the year.  Drupal 7 is likely not going to ship until May of next year at the absolute earliest, so we're discussing something that involves a year's warning at least.  (And if we were to wait until Drupal 8, we're talking about a 2 year delay until we can fully embrace PHP 5.)

Having permitted "value-add" for PHP 5 in core is, honestly, a nice idea but not feasible in practice.  That would mean that the form system, menu system, database system, blocks, nodes, throttle, theming system, watchdog, etc. can't use PHP 5.  That leaves maybe Aggregator as a core system that could use PHP 5 and get substantial benefit from it.  Dries actually OKed that policy for Drupal 6 about 2 months ago, but nothing has happened with it because there's not much in core that we really could do that to. :-)  

I had suggested adding a taxonomy to project nodes that could flag a minimum PHP version shortly after DrupalCon, but I like the idea of putting it in the info file better.  PHP has bulit-in version comparison utilities.  Dries, dww, is that something doable/allowable?

Optionally offering extended Drupal 6 support would be fine with me, and that's something we could decide "on the fly" later when we see what the market looks like.  I hesitate to do that to poor Gabor, though, since that wasn't the plan when he agreed to be D6 maintainer. :-)  Gabor, your thoughts?

--Larry Garfield

On Tue, 26 Jun 2007 14:58:47 -0400, "Scott Trudeau" <strudeau at umich.edu> wrote:
> First: Kudos to everyone for so heavily weighing the needs of users
> who clearly can't even participate at the developer level -- I'm sure
> anyone active on this list would suffer little pain from a php5-only
> D7.
> 
> Second: The underlying concensus seems to be that this move should
> probably happen sooner or later, and the debate is about how soon.
> 
> IMO, there are few strong arguments for NOT providing a php5-only D7.
> If, in hindsight, it proves to be a mistake (IMO, very unlikely), we
> can always continue to support D6 and, in the absolute worst case
> scenario, abandon php5-only benefits and begin backporting.
> 
> For the broader push for php5-only OS web apps, I think it would make
> sense to identify a range of web hosts that already provide php5,
> those that do not, and provide documentation on how to export a site
> from the latter set and import a site to the former set -- if we
> expect a large number of users to want to upgrade from php4-only
> hosts.  Is there any evidence for large numbers of Drupal users who
> will likely want to upgrade who are truly "stuck" on a php4-only host?
>  This is effectively, btw, an organized boycott of php4-only hosts --
> but I see that as a good thing.
> 
> Hell, perhaps an enterprising consultant or shop could solicit
> "sponsorships" from php5-capable hosts to draft "importing a Drupal
> site" to their platform and use some of that sponsorship money to help
> pay to draft "export" documentation for uncooperative hosts.
> 
> This decision would be a little easier to gauge if we had numbers
> describing things like how many D4.6/4.7/5.x/6 sites there out there?
> How "good" are sites at keeping up to date with major version changes
> (i.e., how many sites tend to upgrade, how long is the lag between
> release and upgrade, on average, etc.)?  How many sites are currently
> active on php4-only hosts? Etc.  Do we have any sense of those
> numbers?  Is there a good way to poll the wider Drupal community to
> get their thoughts?  I.e., how many people on support know this
> conversation is happening?
> 
> FWIW, I also think that it might be a good thing to plan a major
> change on a nice, long timeline and expect to provide extended support
> for D6 for longer than usual -- as Chris Johnson points out, it's very
> difficult to keep up with the rapid-fire Drupal release cycle.
> 
> Scott
> 
> On 6/26/07, dmitri <dmitri at dmitrizone.com> wrote:
>> We could potentially make an extended support cycle for Drupal 6,
>> e.g. still when Drupal 8 comes out, however D7 will have php5
>> required for some of core, as some of us have said, and D8 will be
>> php5 only (but 6 will still be supported)
>>
>> On Jun 26, 2007, at 7:33 AM, Earnie Boyd wrote:
>>
>> > Quoting Dries Buytaert <dries.buytaert at gmail.com>:
>> >
>> >>
>> >> On 21 Jun 2007, at 08:38, Boris Mann wrote:
>> >>> Mark my words: a PHP5-only Drupal 7 will leave many, many Drupal
>> >>> users behind.
>> >>>
>> >>> It's OK...every full Drupal update leaves many Drupal users
>> >>> behind  for a significant portion of time. Ponder that :P
>> >>
>> >> Except that this time, we risk leaving 70% of the install base
>> >> behind.  The amount of intelligent/constructive feedback to this
>> >> thread has been surprisingly low.  Let's stick to facts and real
>> >> arguments, please.  I'd like to see a _real_ discussion here.
>> >>
>> >
>> > How do we quantify the 70%?  Does all of that 70% have no choice to
>> > move to PHP5 if they want?  How can we help those who want to move
>> > to Drupal 7 but can't because their stuck on PHP4 find a path?
>> > What preparation will early announcement have on the 70% to help
>> > reduce that number?  Those who don't want to upgrade will never
>> > upgrade; should we reduce that number from the 70%?  We could add a
>> > warning to Drupal 6 that Drupal 7 is going to require PHP5 to
>> > prepare the masses who upgrade to it.  Unless we approach this as
>> > all or nothing IMO we will forever remain at PHP4.
>> >
>> > It is easy for modules to begin to require PHP5 with a simple try/
>> > catch coding phrase.  Since try/catch cannot be emulated it is a
>> > must to move to PHP5 to use the code.  So in order to help reduce
>> > the migration to PHP5 I do agree that some modules should begin
>> > requiring it for Drupal 6.  I find PHP5 faster than PHP4 so
>> > therefore remaining at PHP4 makes little sense since we are looking
>> > for speed improvements.  The issue is, for those who have the need
>> > to remain at PHP4 how can we continue to support them?  We let them
>> > remain with Drupal 4, 5 and 6 until such time they are ready to
>> > move forward.
>> >
>> > Earnie
>>
>>



More information about the development mailing list