> -----Original Message----- > From: Johannes Schlüter [mailto:johan...@schlueters.de] > Sent: Thursday, November 25, 2010 9:21 AM > To: Andi Gutmans > Cc: Jani Taskinen; da...@php.net; PHP Internals > Subject: RE: [PHP-DEV] Re: Hold off 5.4 > > On Thu, 2010-11-25 at 17:11 +0000, Andi Gutmans wrote: > > For what it's worth the changes we've made in the Zend Engine around > > performance and memory use could warrant a major version. Every major > > version of PHP in the past has been driven foremost by major engine > > overhauls. > > Yes, larger changes to the engine changed the major number. But all of them > had a big effect. This is "only" performance. No functionality. 90% of the > users > won't notice it. Whereas everbody oticed the change from3 to 4 or the new > object model in 5. Changing the major number has two big > effects: a) marketing b) more fear for doing the upgrade. > > I value b) as the more relevant factor to monitor.
I agree it is border line. I didn't say I feel strongly about it but I also wouldn't dismiss the changes we are making in PHP-next both from a core runtime point of view, backwards compatibility + new functionality as a minor version. As technologies mature new major versions are often a bit more balanced which makes sense given we have such a huge user base. This is no different in the Java world, C++ as it matured or some other technologies. From a core runtime point of view I think the changes are actually quite far reaching. I also believe there's more that we can do and want to try and do. From a BC point of view I do think it's an opportunity to clean up quite a bit. I am not an advocate of going crazy but I think we've already identified a few areas as a group that we feel comfortable with that strike a good balance between BC and helping move things forward. I think these are major version changes not minor version changes. From a functionality point of view I actually think there's some good functionality here: - Traits (I think this is major) - Some additional language improvements around array dereferencing, configurable mbstring support at runtime (we still need to do some work there), closure enhancements, ... - Some major and minor improvements in modules such as FastCGI, JSON, hashing, ... I think this is definitely more than minor version. I agree it may feel somewhat light as a major version but there is no such thing as a manor version :) In the spirit of release early and often I would actually gravitate towards the major version and start with clean slate although I also understand the other side of the world. In this scenario I would not use the excuse of a major version to go crazy though. Keep it sane and similar to what we're discussing now with maybe some additional engine improvements, additional cleanup and some extension work that can probably still be done. It has to be extremely finite (short list) and managed in a good release process. I do think if we continue to do "major minor" versions like we've done in the 5.x branch we will probably stay in the 5.x branch perpetually and it could be confusing to our users when they get major BC breaks and changes within the same major version. Andi
