On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield <la...@garfieldtech.com> wrote: > 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. > I think that the hosting companies will adapt as slow as they can, so if we give more frequent releases, then they will (have to) upgrade more often. Additionaly if we release more frequently but with fewer changes, then the developers can adapt more easily, because they have to watch out for one or two change at a time, not a whole lot of changes.
Tyrael > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
