On Fri, Mar 19, 2010 at 3:31 AM, Ferenc Kovacs <tyr...@gmail.com> wrote:
> 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. > Being a guy who both runs a small hosting shop and spends lots of time doing development. I would greatly appreciate more frequent, but smaller releases. I just finally got 5.3 rolled out this week, and have been wanting it for months for the performance improvements in realpath, but have been hindered by the large list of things it would throw warnings about. The other side of hosting is that most of your clients don't keep on top of versions of their installed software. Even app developers don't want to go make changes to a 5 year old app just because PHP has decided that something is no longer a good practice. My guess is that I'm in the minority of hosts that want to upgrade PHP for new features. Part of that is probably driven by being a app developer for most of my job. -- -Nathan Gordon If the database server goes down and there is no code to hear it, does it really go down? <esc>:wq<CR>
