Move PHP version to 5.4 to drupal 8's minimum version.

I will try and work on this some time next week.... but other things are more pressing....

It is certainly not as simply as changing the config.json file :-

the recipe in cookbooks/site/php/recipes/source.rb

remote_file "#{Chef::Config[:file_cache_path]}/php-#{version}.tar.gz" do
  source "#{node['php']['url']}/php-#{version}.tar.gz"
  checksum node['php']['checksum']
  mode "0644"
  not_if "which php"
end

This is hopelessly out of date, when the script tries to download the relevant tar.gz file it get mangled up in a redirect. The php site has started unhelpfully
redirecting the user to a mirror site which causes the script to "spit the dummy"..

I was looking around the web ... these things should be modular and many people have the same problem ... so I was hoping to beg borrow or steal someone else recipe..

This blog seems a place to start

http://blog.vandenbrand.org/2012/03/06/how-to-create-a-vm-with-php-5-4-u...

There are a few other which give similar instructions, which if I cannot find a working cookbook, then one need to be implemented.

I knew Trusty Tahr would solve our problems, I just forgot it was this close ( 10 days! )

I am sure more than a few things will change ...

From php.rb

pkgs = [
  "php5-gd",
  "php5-mysql",
  "php5-mcrypt",
  "php5-curl",
  "php5-dev"
]

It bothers me, a little, that we are constrained to working from an initial virtual image... locking down specific packages to a version range enables self consistency checks to work in the background....

1) Has a developer, by adding a new feature, introduced an incompatibility issue with a unrelated requirement? It would be nice if that generated errors...

2) I know this is a development project - but in production can hackers obtained an advantage by downgrading/upgrading packages. Periodic reprovisioning gives some degree of protection...

I will google around, and see if others have, from the beta releases of 14.04 LTS , come up with a list of typical package extensions useful for php

[Warning issue creep] Should this issue be renamed "Prepare for Trusty Tahr"?

Just mulling over the problems of keeping upto date with the slowly evolving requirement of drupal8 which respect to php and its subprojects
and how they will change rapidly before official release, and then more slowly once out in the wild.

Core has a outstanding critical task to go the way of symfony, to be more modular and use composer to install...

If VDD adopted this install method, it would ensure the development environment proceeded in lock step with drupal core in all circumstances...

Anyway I am providing a link to the issue.

I am not leaving, this issue in the strictest sense...I am still eager to discuss the best way forward, here

BUT I will put my energies into solving the wider issue ( #197220 )

Thanks for the pro tip..

I am speaking of working practises in symfony.. is it still a controversial subject in Drupal, so please don't take what I have to say as final.....

So here is a link to a blog which explains the difference between composer update and composer install

http://adamcod.es/2013/03/07/composer-install-vs-composer-update.html

In short :-

Compose update should be a run in a development environment and used to pick up the latest self-consistent set of versions of the packages...

Use composer install... in the production environment to take the composer.lock file and ensure production is the exact copy of your development state at the moment of release ...

Here is a stackoverflow question ( please ignore the fact that it is puppet ) but the question is how can I run composer update when vagrant up is running
http://stackoverflow.com/questions/20401118/how-to-run-composer-update-v... - so composer running on a timeout...

It is difficult for me to answer your php5.3 question - Since D8 is using traits now it cannot be expected to run in php 5.3 and the integrity check warning should be immediate and fatal... I have some sympathy for your position since under this scheme we would have to announce a potential loss of functionality. As was hinted at earlier
VDD will not be able to support D7 with a wide range of contrib modules running in parallel with D8..

To my mind all solutions to this would inevitably have to run two different virtual servers one for d7 one for d8....

Anyway I hope this helps