On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote: > +1 For shorter release cycles. Shorter release cycles could also allow us > to move major releases immediately to bug and security fixes only. I've > never been a fan of seeing additional features added in minor releases. > It's confusing enough to try and keep track of features from one major > release to the next, but then we add in features on minors as well. "That > feature was added in 5.3.1". Obviously this was not a good option when > major releases were at 12 months or more apart. If we can shorten the > cycle, I think it might be a good idea to visit how quickly each release > is frozen to bug and security fixes only. This may just be a developmental > pet-peave of mine, I'm sure I'll hear about it soon if the idea is > unfavorable. > > As an additional note to this, performance patches which don't add > additional features but only increase speed would still be fair game. > > P.S. 2: Reduced release cycle times might reduce the burdens on RMs as well > by allowing them to commit to shorter time periods of release management > responsibility. Not that I hear any of them complaining, just thinking this > might be another good reason to give it a try. > > Eric Lee Stewart
If I could step in for a moment, while there's certainly advantages to shorter release cycles that others have mentioned there's another factor that has to be considered: Backward compatibility would have to be much more tightly monitored. Out in the shared hosting world, we're at the mercy of web hosts and Linux distributions. They don't like to upgrade stuff if they don't have to, and often times not even then. It wasn't that long ago that we needed an industry-wide boycott, essentially, to force PHP 5 at all. Most hosts aren't on 5.3 yet. That means any mass-market PHP projects (Wordpress, Drupal, Joomla, CakePHP, Symfony, CodeIgnighter, etc.) are still working with 5.2 at best, and it may be some time before the "I don't have root on my server and don't know how to compile stuff myself" crowd (read: the vast majority of the market) is able to leverage 5.3. When significant releases are 2-3 years apart, web hosts can expect to have to put in actual work every couple of years and mass-market developers can expect to have to beat their hosts over the head with a stick every few years. If significant releases are going to be every year, then it has to still be easy and safe for hosts to upgrade. Preferably it has to also make servers faster because then they have an incentive to upgrade themselves. If hosts don't upgrade, it doesn't matter what amazing new features PHP has. Most people can't use 'em. I'm not against a more planned, frequent release cycle but I want to make sure that the upgrade treadmill is kept walkable or else it won't matter that PHP has new features. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
