On Fri, Mar 19, 2010 at 11:12 AM, Nate Gordon <nlgor...@gmail.com> wrote:
> 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> > I guess I'm missing the point on this. We all know hosting companies are slow to adopt our changes. But does it really have anything to do with the time interval between our releases. I would think the more pressing issue would be BC which is not a function of the time interval but rather a function of actual changes implemented in a release. I don't remember any one in this thread insinuating that we'll be making diversions from the long lasting goal of maintain BC whenever it's even remotely possible. Best case scenario when only considering the time interval. We see a little better adoption if short release cycles mean a new release gets push prior to a hosting company's evaluation period for rollout changes. Worst case scenario, a perception is generated by the fact we appear to be moving ahead faster and they appear to be falling behind even faster. But I think the reality will be that we are still doing roughly the same amount of changes either way. We'll just be pushing it out in smaller chunks. Eric Lee Stewart
