I agree with MPD that there are few people who are using Drupal 8 on an everyday basis, except those people involved in the development of Drupal 8 in some degree. I don't expect answers from those people, though, as I imagine Drupal 8, and their work, take most of their time.
Apart the fact that Drupal 8 is still evolving, and that libraries are still being included (Guzzle has been included in one of the recent commits), the most important issue I see so far is that Drupal.org API has problems parsing Drupal 8 code to build the documentation pages. (I remember I read a issue report on Drupal.org, probably on the Drupal.org webmasters queue, but I have also noticed the issue myself.)
If you look at CronController.php, you will notice the source code is not shown, while that file is not empty.
/**
* @file
* Definition of Drupal\system\CronController.
*/
namespace Drupal\system;
use Symfony\Component\HttpFoundation\Response;
/**
* Controller for Cron handling.
*/
class CronController {
/**
* Run Cron once.
*
* @return Symfony\Component\HttpFoundation\Response
* A Symfony response object.
*/
public function run() {
// @todo Make this an injected object.
drupal_cron_run();
// HTTP 204 is "No content", meaning "I did what you asked and we're done."
return new Response('', 204);
}
}
This means that when searching for CronController, Drupal.org API will show you a link to the CronController.php file, which then doesn't show any code.
While having few people who are working with Drupal 8 code, or who are testing Drupal 8 in some way, means the answer for a Drupal 8 question could come after months, the fact we are not always able to provide a link to a documentation page for a class/method/function limits in someway the usefulness of the answers. It is true I could provide a link to a line of the Git repository, but the code that is found at that line changes when the file is edited, which means that such links would not anymore useful once the file is changed from a commit.
That it probably happen in very few cases, but to me ready to answer means having the right instruments for answering, and being able to link to the necessary function/method documentation is (IMO) indispensable for answering.
Having a computer running PHP 5.3.5 is not something difficult to get. Considering that PHP 5.3 is recommended also for Drupal 6, I would expect PHP 5.3 starts to be used to check the developed code. PHP 5.3 is also probably used from most of the host providers (the host provider I am using passed to PHP 5.3.13 right a month ago), and there should not be any reason to use PHP 5.2 for test sites, if not in the case the customers are still running PHP 5.2. Even in that case, there should be at least a computer running PHP 5.3.
