Re: [PHP-DEV] PHP 5.4 branch and trunk
On Fri, 19 Mar 2010, la...@garfieldtech.com wrote: > The point is that, for instance, PHP 5.3 was not a trivial upgrade for coders > or hosters. Sure it's mostly compatible, and you certainly can write code > that works from 5.0->5.3 just fine, and if not then you're probably doing > something wrong... but that's most of the PHP code out there right now. :-) > And naturally you can't test your code against 5.3 until it's out. Sure you can, there are SVN snapshots and release candidates. We release those so that you *can* test your code! regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 3/19/10 10:34 AM, Eric Stewart wrote: 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? :wq 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 The point is that, for instance, PHP 5.3 was not a trivial upgrade for coders or hosters. Sure it's mostly compatible, and you certainly can write code that works from 5.0->5.3 just fine, and if not then you're probably doing something wrong... but that's most of the PHP code out there right now. :-) And naturally you can't test your code against 5.3 until it's out. So things like "this didn't used to throw a warning but should have all along, so now it does" are BC breaks, from a hoster's point of view. If they upgrade, some of the random code they host will start throwing warnings when it didn't used to. So they don't upgrade, and Linux distros take their time (not everyone is as behind as Red Hat, but the current Ubuntu stable still ships 5.2 for instance), so devs who don't compile their own PHP can't really test on 5.3... Nastiness. That's what kept PHP 5 back for so long. I guess my point is that one rough upgrade every 3-5 years is something hosts and coders can deal with, mostly. Or one easy upgrade every 1-2 years is something hosts and coders can deal with, mostly. But a rough upgrade every 1-2 years is not something that most hosts and coders can keep up with. And the definition of "rough" in this context is really strict. So if non-bug releases are going to move from 3-5 years to 1-2 years, it also needs to be kept easy, not rough, which means a much tighter reign kept on BC breakage, even low-level "you should be doing it this way now" breakage. The long-tail of versions that mass-market projects need to support is then much longer, too, so they need to be able to write code that will run smoothly on 5.2, 5.3, 5.4, and 5.5, even if they don't use anything not in 5.2. Does that explain my concern better? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.ph
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Fri, Mar 19, 2010 at 11:12 AM, Nate Gordon wrote: > On Fri, Mar 19, 2010 at 3:31 AM, Ferenc Kovacs wrote: > > > On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield > > 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? > :wq > 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 mo
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Fri, Mar 19, 2010 at 3:31 AM, Ferenc Kovacs wrote: > On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield > 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? :wq
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield 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
Re: [PHP-DEV] PHP 5.4 branch and trunk
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
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Thu, Mar 18, 2010 at 4:50 PM, Lukas Kahwe Smith wrote: > > On 18.03.2010, at 18:48, David Soria Parra wrote: > > On 2010-03-18, Pierre Joye wrote: >> >>> On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote: >>> >>> I do agree that we need to do major releases more often, but just setting a time already feels wrong. It's still open source, so it's ready when it is ready. That of course should not mean that we should keep on adding features endlessly. >>> >>> for releases, avoid commits rushes right before the freeze, etc. As >>> I've been said before already, I'm all for a fixed release cycle, it >>> is then much easier to define clear priorities and roadmaps. >>> >> >> +1. i think having a fixed release cycle has nothing to do with >> being opensource or not but with being more predictable for people >> depending on release dates. >> > > right. and again i think i was quite explict in my original mail that > common sense still applies. if we have a buggy release we will obviously not > release it just because. as for having enough to actually warrant a release > i do not ever remember a time where there werent atleast a handful feasible > proposals in varying size on the table. > > regard > Lukas > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > +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
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 18.03.2010, at 18:48, David Soria Parra wrote: On 2010-03-18, Pierre Joye wrote: On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote: I do agree that we need to do major releases more often, but just setting a time already feels wrong. It's still open source, so it's ready when it is ready. That of course should not mean that we should keep on adding features endlessly. for releases, avoid commits rushes right before the freeze, etc. As I've been said before already, I'm all for a fixed release cycle, it is then much easier to define clear priorities and roadmaps. +1. i think having a fixed release cycle has nothing to do with being opensource or not but with being more predictable for people depending on release dates. right. and again i think i was quite explict in my original mail that common sense still applies. if we have a buggy release we will obviously not release it just because. as for having enough to actually warrant a release i do not ever remember a time where there werent atleast a handful feasible proposals in varying size on the table. regard Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
I propose that sort of a unicode working group forms but much less formal than what I make it sound like. I think the discussions can remain on internals@ and hopefully alternative approaches will be documented as RFCs. But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever. So how would that "group" differ from just internals@ ? hmm i think i specifically addressed this in my previous email: "But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever." so i want to make sure that a handful of people feel responsible to drive this thimg forward as its a topic that requires a fair bit of research. of course anyone can contribute at anytime as well and with thid group they also have people they can contact to be brought up to speed quickly via a chat or phone call. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 2010-03-18, Pierre Joye wrote: > On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote: > >> I do agree that we need to do major releases more often, but just >> setting a time already feels wrong. It's still open source, so it's >> ready when it is ready. That of course should not mean that we should >> keep on adding features endlessly. > > for releases, avoid commits rushes right before the freeze, etc. As > I've been said before already, I'm all for a fixed release cycle, it > is then much easier to define clear priorities and roadmaps. +1. i think having a fixed release cycle has nothing to do with being opensource or not but with being more predictable for people depending on release dates. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote: >> As for unicode, I would like the next release to be planned >> independently of finding a solution for unicode, but with the clear >> option that it will be included if we find a good solution in time >> (like I said I think it would be good to shoot for a final release >> summer 2011, so beta phase in early 2011). > > I do agree that we need to do major releases more often, but just > setting a time already feels wrong. It's still open source, so it's > ready when it is ready. That of course should not mean that we should > keep on adding features endlessly. Maybe because it is the only way to garantee a reasonable time frame for releases, avoid commits rushes right before the freeze, etc. As I've been said before already, I'm all for a fixed release cycle, it is then much easier to define clear priorities and roadmaps. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, 16 Mar 2010, Lukas Kahwe Smith wrote: > On 16.03.2010, at 16:58, Derick Rethans wrote: > > other stuff: > http://wiki.php.net/todo/php60 > http://wiki.php.net/todo/backlog yeah, I know there is other stuff, I was just listing a few examples of things I remembered. Both lists require some scrutiny as I can see from a quick glance. > As for unicode, I would like the next release to be planned > independently of finding a solution for unicode, but with the clear > option that it will be included if we find a good solution in time > (like I said I think it would be good to shoot for a final release > summer 2011, so beta phase in early 2011). I do agree that we need to do major releases more often, but just setting a time already feels wrong. It's still open source, so it's ready when it is ready. That of course should not mean that we should keep on adding features endlessly. > I propose that sort of a > unicode working group forms but much less formal than what I make it > sound like. I think the discussions can remain on internals@ and > hopefully alternative approaches will be documented as RFCs. But what > I mean with working group is a list of a handful of names who feel > responsible to keep this topic moving until a solution is found and > who people know they can contact if they want to chat or whatever. So how would that "group" differ from just internals@ ? > Again if these guys find a workable solution that can be implemented > this year and I am all for putting it into the next release. It might also be possible to introduce Unicode step by step. Not everything does necessarily have to be done in one release. regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Thu, Mar 18, 2010 at 5:46 PM, Derick Rethans wrote: > On Tue, 16 Mar 2010, Zeev Suraski wrote: > >> At 17:58 16/03/2010, Derick Rethans wrote: >> > - Declare 5.2 security fixes only (Something for Ilia to declare). >> > - Declare 5.3 bug fixes only (and ini-mini features if so desired) >> > (Something for Johannes to declare). >> > >> > Once that's done, I'd like to: >> > >> > - Recreate trunk from the 5.3 branch. >> >> >> +1 >> >> > - Ilia's scalar type hint patch. There are RFCs: >> > http://wiki.php.net/rfc/typechecking >> >> A while ago Lukas and I prepared an alternative RFC that I'd like >> people to review - now that it's becoming relevant again I'd like to >> revive that discussion: http://wiki.php.net/rfc/typecheckingweak > > I'm aware of that. I was just listing a bunch of features. To avoid > confusion, I'll start a new thread for each of them. Please let the respective developers do it when they are ready to discuss them. We don't have to begin every single discussion now and here. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, 16 Mar 2010, Zeev Suraski wrote: > At 17:58 16/03/2010, Derick Rethans wrote: > > - Declare 5.2 security fixes only (Something for Ilia to declare). > > - Declare 5.3 bug fixes only (and ini-mini features if so desired) > > (Something for Johannes to declare). > > > > Once that's done, I'd like to: > > > > - Recreate trunk from the 5.3 branch. > > > +1 > > > - Ilia's scalar type hint patch. There are RFCs: > > http://wiki.php.net/rfc/typechecking > > A while ago Lukas and I prepared an alternative RFC that I'd like > people to review - now that it's becoming relevant again I'd like to > revive that discussion: http://wiki.php.net/rfc/typecheckingweak I'm aware of that. I was just listing a bunch of features. To avoid confusion, I'll start a new thread for each of them. with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Wed, 17 Mar 2010, Antony Dovgal wrote: > On 03/16/2010 07:13 PM, Derick Rethans wrote: > >> + merge php-fpm branch? > > > > Can't see why not. Is there an RFC for this? > > No, there are no RFCs on that. > Just copy sapi/fpm to 5_4 and you've merged it. There is no 5_4, but still, I think there should be at least some docs on what it does, and which features and problems it addresses. Saves the doc team some work as well, and we know what we're getting ourselves into. with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.4 branch and trunk
> -Original Message- > From: Antony Dovgal [mailto:t...@daylessday.org] > Sent: Wednesday, March 17, 2010 2:25 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk > > On 03/16/2010 07:13 PM, Derick Rethans wrote: > >> + merge php-fpm branch? > > > > Can't see why not. Is there an RFC for this? > > No, there are no RFCs on that. > Just copy sapi/fpm to 5_4 and you've merged it. I think it'd actually be a good idea to have RFCs for major pieces of new functionality even if they are retroactively written for cases such as sapi/fpm and new output buffering. Quite a bit of time has passed and it's good documentation for the new releases + gives people an opportunity to review as we work towards the next big release. It may just mean refactoring a past email that describes this in detail so doesn't have to be huge effort but would be good to be more organized with the new release. Andi
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, Mar 16, 2010 at 22:12, Lukas Kahwe Smith wrote: > > On 16.03.2010, at 19:23, Hannes Magnusson wrote: > >> You didn't even list the mbstring patch.. that was discussed and as >> far as I remember everyone thought it was great idea, just not in a >> stable branch. > > > Is this tone really necessary? One you are argueing for more flexibility and > then you are shooting the messenger because in a long list he forgot one > thing (there are probably a few others .. we might want to go through the > todo wiki pages for more)? > "tones" are misleading :] One of the things we already discussed before this thread was to attempt alternative ways to approach "the unicode problem". That mbstring patch is one of those ways. Its nonintrusive (well, to other parts of the language) and should be relatively backwards compatible and improves the extension quite a lot. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, 16 Mar 2010, Stanislav Malyshev wrote: > > Does that mean you want to take up a > > - strict RFC-and-after-3months-discussion-before-commit policy > >(i.e. killing the scratching-an-itch spirit of PHP) > > - "I'm going to commit this patch tomorrow" mail to internals@ > >(i.e. killing "I need this functionality, maybe others do to" spirit of > > PHP) > > Probably something like "I have this patch and I wrote this RFC, please > discuss", then wait reasonable* time for discussion and reasonable* consensus > before commit, and for reasonably* small patches "I'm going to commit it in 2 > days unless somebody objects" would work > > (*) I know definitions of "reasonable" differ but I have faith we find a > common ground. Yup, that's what I was thinking about. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Wed, Mar 17, 2010 at 10:25 AM, Antony Dovgal wrote: > On 03/16/2010 07:13 PM, Derick Rethans wrote: >>> + merge php-fpm branch? >> >> Can't see why not. Is there an RFC for this? > > No, there are no RFCs on that. > Just copy sapi/fpm to 5_4 and you've merged it. There is no 5.4 either, trunk is the way for now. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 03/16/2010 07:13 PM, Derick Rethans wrote: >> + merge php-fpm branch? > > Can't see why not. Is there an RFC for this? No, there are no RFCs on that. Just copy sapi/fpm to 5_4 and you've merged it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 17 March 2010 16:50, Jan Schneider wrote: > How about 5.3.99? A lot of projects use this for pre-releases, but it still > might make sense. I'm wary of sticking with anything starting with 5.3 if we're going to break binary compatibility on the new trunk (which we presumably are) — it undermines the usual binary compatibility guarantees on "stable" branches, even given that the new trunk is a development branch. As Johannes said: >> We can still increase the number if needed. I completely agree. IMO, there's nothing wrong with calling it 5.4 now and renumbering it to 6.0/7.0/whatever (in the same manner as what Postgres are currently doing with 8.5 becoming 9.0) later if it makes sense to. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
Zitat von Johannes Schlüter : On Tue, 2010-03-16 at 22:13 +0100, Lukas Kahwe Smith wrote: On 16.03.2010, at 16:58, Derick Rethans wrote: > Before we add features, they need to be discussed whether we want to > have them. As version name for it I would like to use "trunk-dev" (and > not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving. > Right now, there are the following features that I can see we should > think about: Since we do not know the name of the next version yet, maybe its best to base the name on what version it will have as a predecessor and add support for this in version_compare()? Something like "5.3post". Ok this isnt a good suggestion, but I hope you get what I am suggesting. We need a version number which can be represented as a numeric value like #define PHP_VERSION_ID 50303 to help extension authors; as said on IRC 5.4 is the only sane choice there. We can still increase the number if needed. How to document this is a good question... How about 5.3.99? A lot of projects use this for pre-releases, but it still might make sense. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, 2010-03-16 at 22:13 +0100, Lukas Kahwe Smith wrote: > On 16.03.2010, at 16:58, Derick Rethans wrote: > > > Before we add features, they need to be discussed whether we want to > > have them. As version name for it I would like to use "trunk-dev" (and > > not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving. > > Right now, there are the following features that I can see we should > > think about: > > > Since we do not know the name of the next version yet, maybe its best to > base the name on what version it will have as a predecessor and add > support for this in version_compare()? Something like "5.3post". Ok this > isnt a good suggestion, but I hope you get what I am suggesting. We need a version number which can be represented as a numeric value like #define PHP_VERSION_ID 50303 to help extension authors; as said on IRC 5.4 is the only sane choice there. We can still increase the number if needed. How to document this is a good question... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 16.03.2010, at 16:58, Derick Rethans wrote: > I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved Eventually it should be deleted, if it helps at all in merging the OB change then it should be kept until that happens, otherwise it can be deleted now imho. The new 5.3 based trunk will emerge soon I am sure, but until then lets not bother with having to merge those changes. > trunk to the branch FIRST_UNICODE_IMPLEMENTATION. +1 > The next things to do is to re-create trunk from PHP 5.3; I've hold off > that for now, but I'd like to do the following soon: > > - Declare 5.2 security fixes only (Something for Ilia to declare). > - Declare 5.3 bug fixes only (and ini-mini features if so desired) > (Something for Johannes to declare). +1 > - the new output buffering mechanism (I can not really see why we would > not want this) +1 > - traits, there are also RFCs: > http://wiki.php.net/rfc/horizontalreuse > http://wiki.php.net/rfc/nonbreakabletraits +1 other stuff: http://wiki.php.net/todo/php60 http://wiki.php.net/todo/backlog That being said I think until we know if the next version will be a new major version, we should hold off on BC breaking cleanup stuff likes dropping register globals and friends. But we still might bundle APC with the next release for example, even if its not 6.0 .. -- As for unicode, I would like the next release to be planned independently of finding a solution for unicode, but with the clear option that it will be included if we find a good solution in time (like I said I think it would be good to shoot for a final release summer 2011, so beta phase in early 2011). I propose that sort of a unicode working group forms but much less formal than what I make it sound like. I think the discussions can remain on internals@ and hopefully alternative approaches will be documented as RFCs. But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever. Again if these guys find a workable solution that can be implemented this year and I am all for putting it into the next release. If not so be it, because I think the lesson learned in all of the PHP6/PHP5.3 release nightmare is that we should have regular releases. So I say we shoot for the release following the next one to come out in the summer of 2012. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 16.03.2010, at 16:58, Derick Rethans wrote: > Before we add features, they need to be discussed whether we want to > have them. As version name for it I would like to use "trunk-dev" (and > not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving. > Right now, there are the following features that I can see we should > think about: Since we do not know the name of the next version yet, maybe its best to base the name on what version it will have as a predecessor and add support for this in version_compare()? Something like "5.3post". Ok this isnt a good suggestion, but I hope you get what I am suggesting. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 16.03.2010, at 19:23, Hannes Magnusson wrote: > On Tue, Mar 16, 2010 at 16:58, Derick Rethans wrote: >> Before we add features, they need to be discussed whether we want to >> have them. > > Does that mean you want to take up a > - strict RFC-and-after-3months-discussion-before-commit policy > (i.e. killing the scratching-an-itch spirit of PHP) > - "I'm going to commit this patch tomorrow" mail to internals@ > (i.e. killing "I need this functionality, maybe others do to" spirit of PHP) Its all a question about the scope of the change obviously. There is some tipping point where it makes sense for an RFC. Remember an RFC not only serves decision making, but also provides some level of documentation (on which the final documentation can be build) for past generations (this is why I for example wrote the ifsetor RFC after we decided that we cannot currently implement it). So like Stas said .. common sense still rules. > I would much rather have a development branch which ""everything > goes"" (like it used to) and then make it up to the release manager to > merge the features he wants in "his branch" (DVCS style) I dont think we ever had an "everything goes" HEAD .. lets say in the past we had a small very active core dev team with really short turn around times for decisions because everybody was answering on IRC or mailinglists within minutes. As a result decisions (not always for the better) were made in a much shorter timeframe than the current availability of core developers affords us. >> - Ilia's scalar type hint patch. > > And which of Ilias patches are you referring to? The original one > (which is identical to the patch I sent in November 2006) or the > "fucking eyh, I need to please everyone so this can be in 5.3 - but > still got rejected" patch? I think he clearly pointed to the wiki page which lists 3 proposals. He is just suggesting we should finalize which one we want and get it in. > You didn't even list the mbstring patch.. that was discussed and as > far as I remember everyone thought it was great idea, just not in a > stable branch. Is this tone really necessary? One you are argueing for more flexibility and then you are shooting the messenger because in a long list he forgot one thing (there are probably a few others .. we might want to go through the todo wiki pages for more)? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
Hi! Does that mean you want to take up a - strict RFC-and-after-3months-discussion-before-commit policy (i.e. killing the scratching-an-itch spirit of PHP) - "I'm going to commit this patch tomorrow" mail to internals@ (i.e. killing "I need this functionality, maybe others do to" spirit of PHP) Probably something like "I have this patch and I wrote this RFC, please discuss", then wait reasonable* time for discussion and reasonable* consensus before commit, and for reasonably* small patches "I'm going to commit it in 2 days unless somebody objects" would work (*) I know definitions of "reasonable" differ but I have faith we find a common ground. And which of Ilias patches are you referring to? The original one (which is identical to the patch I sent in November 2006) or the "fucking eyh, I need to please everyone so this can be in 5.3 - but still got rejected" patch? That's exactly why having RFC is good - one link solves all the questions about "which one is it' :) -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On 03/16/2010 11:00 PM, Johannes Schlüter wrote: > On Tue, 2010-03-16 at 19:11 +0300, Alexey Zakhlestin wrote: >> + merge php-fpm branch? > > If we get a trunk which will be released in a foreseeable timeframe we > don't need to merge this to 5.3 anymore, which had been an old plan. > Tony, do you agree? Makes sense to me. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, 2010-03-16 at 19:11 +0300, Alexey Zakhlestin wrote: > + merge php-fpm branch? If we get a trunk which will be released in a foreseeable timeframe we don't need to merge this to 5.3 anymore, which had been an old plan. Tony, do you agree? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, Mar 16, 2010 at 16:58, Derick Rethans wrote: > Before we add features, they need to be discussed whether we want to > have them. Does that mean you want to take up a - strict RFC-and-after-3months-discussion-before-commit policy (i.e. killing the scratching-an-itch spirit of PHP) - "I'm going to commit this patch tomorrow" mail to internals@ (i.e. killing "I need this functionality, maybe others do to" spirit of PHP) or what exactly do you mean by that? I would much rather have a development branch which ""everything goes"" (like it used to) and then make it up to the release manager to merge the features he wants in "his branch" (DVCS style) > - Ilia's scalar type hint patch. And which of Ilias patches are you referring to? The original one (which is identical to the patch I sent in November 2006) or the "fucking eyh, I need to please everyone so this can be in 5.3 - but still got rejected" patch? You didn't even list the mbstring patch.. that was discussed and as far as I remember everyone thought it was great idea, just not in a stable branch. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, Mar 16, 2010 at 17:54, Pierre Joye wrote: > On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann > wrote: >> Am 16.03.2010 16:58, schrieb Derick Rethans: >>> I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved >>> trunk to the branch FIRST_UNICODE_IMPLEMENTATION. >> >> Why do we need THE_5_4_THAT_ISNT_5_4 > > Right, this branch must be deleted, useless. The OB patch can be > merged again in trunk when trunk has been rebranched. Why exactly do we need to duplicate the work? IMO that branch should be renamed to trunk/ and those 2 or 3 patches to 5.3 to merged into it. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann wrote: > Am 16.03.2010 16:58, schrieb Derick Rethans: >> I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved >> trunk to the branch FIRST_UNICODE_IMPLEMENTATION. > > Why do we need THE_5_4_THAT_ISNT_5_4 Right, this branch must be deleted, useless. The OB patch can be merged again in trunk when trunk has been rebranched. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
Am 16.03.2010 16:58, schrieb Derick Rethans: > I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved > trunk to the branch FIRST_UNICODE_IMPLEMENTATION. Why do we need THE_5_4_THAT_ISNT_5_4 and trunk? trunk should be where the development happens. When the time comes for a release, PHP_X_Y should be branched off of trunk. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, 16 Mar 2010, Alexey Zakhlestin wrote: > On Tue, Mar 16, 2010 at 6:58 PM, Derick Rethans > wrote: > > > Right now, there are the following features that I can see we should > > think about: > > > > - the new output buffering mechanism (I can not really see why we would > > not want this) > > - Scott's big number improvements. Scott, can you explain (in an RFC) > > what exactly this does and how it works? > > - Ilia's scalar type hint patch. There are RFCs: > > http://wiki.php.net/rfc/typechecking > > - traits, there are also RFCs: > > http://wiki.php.net/rfc/horizontalreuse > > http://wiki.php.net/rfc/nonbreakabletraits > > + merge php-fpm branch? Can't see why not. Is there an RFC for this? regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 branch and trunk
On Tue, Mar 16, 2010 at 6:58 PM, Derick Rethans wrote: > Right now, there are the following features that I can see we should > think about: > > - the new output buffering mechanism (I can not really see why we would > not want this) > - Scott's big number improvements. Scott, can you explain (in an RFC) > what exactly this does and how it works? > - Ilia's scalar type hint patch. There are RFCs: > http://wiki.php.net/rfc/typechecking > - traits, there are also RFCs: > http://wiki.php.net/rfc/horizontalreuse > http://wiki.php.net/rfc/nonbreakabletraits + merge php-fpm branch? -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
