I wholeheartedly support this idea. I want the majority of our efforts to go into innovation, as opposed to supporting ancient platforms. We are a framework in it's infancy, and new stuff and getting more adoption is key. Not supporting ancient, deprecated systems.

On that regard, I also suggest that we drop support for 1.0 branch to an absolute minimum. I.e, no fixes are ported over until someone begs for them - and even in that case, theasker should be intimately involved in the actual work. This will allow us to focus on our future - the jQuery-based branch, 2.0

I want to be very cautious about this. There are many _MANY_ enterprise servers out there running very strictly controlled OS builds, such as RHEL, and not all of them (not even RHEL, I believe) officially support PHP 5.3 yet.

Since maintaining backwards compatibility with PHP 5.1 is so trivially easy (don't use any of the esoteric newly added features), I'd hate to alienate anyone using enterprise server software over it.

Yeah, officially, RHEL 5.5 (the latest) only supports PHP 5.1.6, so in the interests of being usable in the enterprise, I want to maintain compatibility with that.

RHEL 6.0 will introduce support for PHP 5.3.1, but isn't out yet, and will take quite a while to gain widespread adoption.

It is a great idea to go for 5.3.

AFAIK
ZF 2 will be exclusive 5.3
Doctrine 2 same.

It is where a new generation of frameworks is now possible.
5.3 is the future and we will not look back in a few months.

Cheers,
tronics

Just to put a point on it, my prod server is running 5.2.2 and has so many dependencies that upgrading at all is nearly impossible, let alone to 5.3. As such, I will be actively working to ensure QCubed works in that environment, as otherwise, it will not meet my needs.

I'm also very unclear of any significant benefits of 5.3 apart from namespaces, which would be too much work to retrofit into QCubed with no real benefit. What do you hope to gain by moving to 5.3 exclusively apart from being able to avoid checking if a function is backwards compatible?

My vote is that QCubed 2.0.X should drop support for php versions prior than 5.2.0 .

QCubed 3.0.X should work with php versions > 5.3.

Who is with me?

I also do a lot of work with Civicrm, and their stable build won't work on 5.3 (their latest beta does, apparently). So besides the fact that many enterprise servers don't support 5.3 yet, and many virtual hosting services don't have 5.3 yet, and many other contributed packages that we might be trying to integrate (like civicrm, or Drupal Aegir) don't support 5.3 yet, I vote we leave it at 5.2 now.

5.2 support has just expired. No more 5.2 updates.
Every single app out there is on the switch.

Basically I think it is ok to ride on the 5.2 horse for a while since we do not have a 5.3 concept ready yet.

Cheers,
tronics

Let's be clear. We definitely support PHP 5.3, and will continue to do so, so there is currently no overhead in making QCubed both 5.1 and 5.3 friendly.

What we're talking about here is actively choosing to use functionality in 5.3 that would break QCubed running on PHP 5.1 or 5.2. My question is: What functionality?

If there isn't any, and the decision to go 5.3 only still doesn't result in it breaking in 5.1 or 5.2, then it seems rather foolish to cut off "official" support for them.