Re: [PHP-DEV] 5.4 Alpha 2
On Tue, Jul 12, 2011 at 01:28, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 7/11/11 4:20 PM, Kalle Sommer Nielsen wrote: I agree, it would make more sense to have the votings over before doing the next Alpha, so theres time to cook up relevant patches and commit them. Well, OK, let's say we delay a week. Vote closes on 16th, and I'd have to pack on 20th, so we get 4 days for people to dust off patches, apply them, check that everything works, etc. I'm not sure it's worth it - I'd rather have another alpha - but let's hear what other RFC authors think. I'd say leave the RFC things out for this alpha. Committing to many things in the last days before alpha just increases the risk of it being b0rked. Plus, I'm in Paris for that week so won't be able to commit my proposed changes anyway ;) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 Alpha 2
Hi! I'm planning to do 5.4 alpha 2 on 14th (Thursday this week), so if anybody has anything urgent for it or any comments/requests, please talk to me ASAP. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha 2
hi, I would rather wait the 2nd wave of RFCs to be adopted/rejected before doing a2, if some has no patch (or far to be ready) or too risky (the int/string/float looks like one to me) should be dropped and delayed to the next release. On Tue, Jul 12, 2011 at 12:53 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'm planning to do 5.4 alpha 2 on 14th (Thursday this week), so if anybody has anything urgent for it or any comments/requests, please talk to me ASAP. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] 5.4 Alpha 2
Hi 2011/7/12 Pierre Joye pierre@gmail.com: hi, I would rather wait the 2nd wave of RFCs to be adopted/rejected before doing a2, if some has no patch (or far to be ready) or too risky (the int/string/float looks like one to me) should be dropped and delayed to the next release. I agree, it would make more sense to have the votings over before doing the next Alpha, so theres time to cook up relevant patches and commit them. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha 2
Hi! On 7/11/11 4:16 PM, Pierre Joye wrote: I would rather wait the 2nd wave of RFCs to be adopted/rejected before doing a2, if some has no patch (or far to be ready) or too risky (the int/string/float looks like one to me) should be dropped and delayed to the next release. Why delay? RFCs are a separate things, and they should be ready for the beta. We have a number of features that need testing - webserver, Zend Signals, XSLT fixes... We'll have another alpha in early August most probably anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha 2
On Tue, Jul 12, 2011 at 1:23 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 7/11/11 4:16 PM, Pierre Joye wrote: I would rather wait the 2nd wave of RFCs to be adopted/rejected before doing a2, if some has no patch (or far to be ready) or too risky (the int/string/float looks like one to me) should be dropped and delayed to the next release. Why delay? RFCs are a separate things, and they should be ready for the beta. We have a number of features that need testing - webserver, Zend Signals, XSLT fixes... We'll have another alpha in early August most probably anyway. If that's the case, well, why not. But if not, we'd to freeze the chosen additions and now rather than later (as per the release RFC). 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] 5.4 Alpha 2
Hi! On 7/11/11 4:20 PM, Kalle Sommer Nielsen wrote: I agree, it would make more sense to have the votings over before doing the next Alpha, so theres time to cook up relevant patches and commit them. Well, OK, let's say we delay a week. Vote closes on 16th, and I'd have to pack on 20th, so we get 4 days for people to dust off patches, apply them, check that everything works, etc. I'm not sure it's worth it - I'd rather have another alpha - but let's hear what other RFC authors think. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, 28 Jun 2011, Stas Malyshev wrote: On 6/28/11 11:35 AM, Ferenc Kovacs wrote: wasn't the alpha1 packaged in the last second? it was packaged on Jun 19, and it was planned to be released on Jun 20. and it did include obvious bugs. No, it was not. It was checked, ensured it builds on all systems I have access too, etc, and it was done in advance of the release. And I'm sure it has bugs - as every alpha in the world does. That's why it is alpha and not final release. The point of alpha is not to provide a stable platform but initial point for the release and flush out bugs by expanding the user base. It's not a production release. But it missed the built-in webserver thing :( regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Wed, Jun 29, 2011 at 12:41 PM, Derick Rethans der...@php.net wrote: On Tue, 28 Jun 2011, Stas Malyshev wrote: On 6/28/11 11:35 AM, Ferenc Kovacs wrote: wasn't the alpha1 packaged in the last second? it was packaged on Jun 19, and it was planned to be released on Jun 20. and it did include obvious bugs. No, it was not. It was checked, ensured it builds on all systems I have access too, etc, and it was done in advance of the release. And I'm sure it has bugs - as every alpha in the world does. That's why it is alpha and not final release. The point of alpha is not to provide a stable platform but initial point for the release and flush out bugs by expanding the user base. It's not a production release. But it missed the built-in webserver thing :( regards, Derick AFAIK that got into it, but the fixes for the related crashes did not. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
AFAIK that got into it, but the fixes for the related crashes did not. Nope, not until alpha2... but it's something to look forward to, and it's another reason for people to continue testing future alpha releases. :) Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Mon, 20 Jun 2011, Stas Malyshev wrote: Since we've got voting on the process RFCs finally going on, after much deliberation we've decided it'd be best to let the votes finish before the first official 5.4 release. Thus, we decided to postpone 5.4 alpha 1 until June 28th (next Tuesday). The updated schedule is at https://wiki.php.net/todo/php54 , please check out. I think we should delay it a little until we have the bugs data back. Bjori has been in contact with them on the phone today. I would also like to point out that Thursday is our general release day, and we have a release process described in detail here: http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614view=markup cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
Hi! I would also like to point out that Thursday is our general release day, and we have a release process described in detail here: http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614view=markup It doesn't say there Thursday is our general release day. If we want to make it so - ok, let's everybody agree on that and put it there. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, Jun 28, 2011 at 6:39 PM, Stas Malyshev smalys...@sugarcrm.com wrote: I would also like to point out that Thursday is our general release day, and we have a release process described in detail here: http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614view=markup It doesn't say there Thursday is our general release day. If we want to make it so - ok, let's everybody agree on that and put it there. What we actually did during the last years was to release on Tuesday or Thursday, with a little preference to release final (stable) on Thursday. 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] 5.4 alpha
On Tue, Jun 28, 2011 at 18:45, Pierre Joye pierre@gmail.com wrote:
On Tue, Jun 28, 2011 at 6:39 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
I would also like to point out that Thursday is our general release day,
and we have a release process described in detail here:
http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614view=markup
It doesn't say there Thursday is our general release day. If we want to make
it so - ok, let's everybody agree on that and put it there.
What we actually did during the last years was to release on Tuesday
or Thursday, with a little preference to release final (stable) on
Thursday.
Little preference?
According http://www.php.net/releases/
array(4) {
[Thursday]=
int(30)
[Tuesday]=
int(3)
[Monday]=
int(3)
[Wednesday]=
int(1)
}
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, 28 Jun 2011, Stas Malyshev wrote: I would also like to point out that Thursday is our general release day, and we have a release process described in detail here: http://svn.php.net/viewvc/php/php-src/trunk/README.RELEASE_PROCESS?revision=311614view=markup It doesn't say there Thursday is our general release day. If we want to make it so - ok, let's everybody agree on that and put it there. I'm actually surprised it isn't in there. I did write that document some eons ago. But anyway, let's add it then :) cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
hi,
On Tue, Jun 28, 2011 at 6:54 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Little preference?
According http://www.php.net/releases/
array(4) {
[Thursday]=
int(30)
[Tuesday]=
int(3)
[Monday]=
int(3)
[Wednesday]=
int(1)
}
So Thursday was the big preference, wed uploads mean stable as we
upload it one day before so they get mirrored when the announce is
sent.
--
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] 5.4 alpha
Hi! On 6/28/11 9:55 AM, Derick Rethans wrote: On Tue, 28 Jun 2011, Stas Malyshev wrote: I'm actually surprised it isn't in there. I did write that document some eons ago. But anyway, let's add it then :) OK, as soon as we are all agreed on Thursday and it's there I'll shift the schedule for next releases so it'll actually be on Thursday, though I'm not sure why would it actually matter :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Jun 28, 2011, at 9:57 AM, Stas Malyshev wrote: Hi! On 6/28/11 9:55 AM, Derick Rethans wrote: On Tue, 28 Jun 2011, Stas Malyshev wrote: I'm actually surprised it isn't in there. I did write that document some eons ago. But anyway, let's add it then :) OK, as soon as we are all agreed on Thursday and it's there I'll shift the schedule for next releases so it'll actually be on Thursday, though I'm not sure why would it actually matter :) The day an alpha/beta is released doesn't feel important, unlike stable releases, but I suppose consistency has its good points. :) I think the main point is to wait for bugs.php.net, which is making real progress and should be available Thursday. Also, it's important to clarify that the [soon-to-be-popular] built-in web server is not part of this alpha because the alpha was tagged a few days before its addition. I think repackaging would be worth it for this case, but waiting for alpha2 is feasible. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
Hi! Also, it's important to clarify that the [soon-to-be-popular] built-in web server is not part of this alpha because the alpha was tagged a few days before its addition. I think repackaging would be worth it for this case, but waiting for alpha2 is feasible. We'll have alpha2 in a month. I'm really not a fan on last minute repackaging, that's when screw ups happen almost every time. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, Jun 28, 2011 at 7:31 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Also, it's important to clarify that the [soon-to-be-popular] built-in web server is not part of this alpha because the alpha was tagged a few days before its addition. I think repackaging would be worth it for this case, but waiting for alpha2 is feasible. We'll have alpha2 in a month. I'm really not a fan on last minute repackaging, that's when screw ups happen almost every time. I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. It takes 1h~ to do it, no big deal. 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] 5.4 alpha
On 06/28/2011 10:43 AM, Pierre Joye wrote: On Tue, Jun 28, 2011 at 7:31 PM, Stas Malyshevsmalys...@sugarcrm.com wrote: We'll have alpha2 in a month. I'm really not a fan on last minute repackaging, that's when screw ups happen almost every time. I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. +1 Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
Hi! On 6/28/11 10:43 AM, Pierre Joye wrote: I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. Really, guys, if we ever want to have scheduled and orderly releases, changing release schedule in the last minute repeatedly and repackaging in the last second is exactly NOT the way to do it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, Jun 28, 2011 at 8:06 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/28/11 10:43 AM, Pierre Joye wrote: I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. Really, guys, if we ever want to have scheduled and orderly releases, changing release schedule in the last minute repeatedly and repackaging in the last second is exactly NOT the way to do it. Usually I would agree, but in the current situation I would vote for the repackaging. we already streched our release date, and going with the current 5.4 HEAD still seems a better idea than with the current alpha. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 alpha
On June-28-11 2:06 PM Stas Malyshev wrote: On 6/28/11 10:43 AM, Pierre Joye wrote: I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. Really, guys, if we ever want to have scheduled and orderly releases, changing release schedule in the last minute repeatedly and repackaging in the last second is exactly NOT the way to do it. IMHO, exactly right. Not much point in having a plan if it isn't followed, and that usually ends up causing problems - what the plan is supposed to prevent. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On 2011-06-28, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/28/11 10:43 AM, Pierre Joye wrote: I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. Really, guys, if we ever want to have scheduled and orderly releases, changing release schedule in the last minute repeatedly and repackaging in the last second is exactly NOT the way to do it. I agree with Stas. Repackaging in the last second might cause troubles and include obvious bugs. I prefer having a some time between packaging and releasing, if it's an alpha or not it doesn't matter. So in this case, to really try to finally stay on schedule , so we should release the already pacakged version and have an alpha2 in two weeks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, Jun 28, 2011 at 8:25 PM, David Soria Parra d...@php.net wrote: On 2011-06-28, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/28/11 10:43 AM, Pierre Joye wrote: I do think we should repackage. There are many issues fixed since last week and it makes no sense to release something not representing what the current 5.4 branch is. Really, guys, if we ever want to have scheduled and orderly releases, changing release schedule in the last minute repeatedly and repackaging in the last second is exactly NOT the way to do it. I agree with Stas. Repackaging in the last second might cause troubles and include obvious bugs. I prefer having a some time between packaging and releasing, if it's an alpha or not it doesn't matter. So in this case, to really try to finally stay on schedule , so we should release the already pacakged version and have an alpha2 in two weeks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php wasn't the alpha1 packaged in the last second? it was packaged on Jun 19, and it was planned to be released on Jun 20. and it did include obvious bugs. so if we already screwed up, we could at least fix what we can instead of releasing a version, which we all know is broken. this can make a bad impression in the early adopters. but I won't whine much about this, just told my 2 cents. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
Hi! On 6/28/11 11:35 AM, Ferenc Kovacs wrote: wasn't the alpha1 packaged in the last second? it was packaged on Jun 19, and it was planned to be released on Jun 20. and it did include obvious bugs. No, it was not. It was checked, ensured it builds on all systems I have access too, etc, and it was done in advance of the release. And I'm sure it has bugs - as every alpha in the world does. That's why it is alpha and not final release. The point of alpha is not to provide a stable platform but initial point for the release and flush out bugs by expanding the user base. It's not a production release. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, Jun 28, 2011 at 21:00, Stas Malyshev smalys...@sugarcrm.com wrote: final release. The point of alpha is not to provide a stable platform but initial point for the release and flush out bugs by expanding the user base. It's not a production release. Exactly. Requiring a working bug tracker. Postponing the release for a week if I can't get in touch with the guys early enough is the logical thing in my opinion. We do however have a 5.4RC out there for some reason.. As for repacking, I totally agree with not repackage - even though it is very annoying that it doesn't include many things people have been working on :) If you opt for waiting another week, I would like to see a retagging+packaging on Tuesday :] -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
Hi! On 6/28/11 12:49 PM, Hannes Magnusson wrote: On Tue, Jun 28, 2011 at 21:00, Stas Malyshevsmalys...@sugarcrm.com wrote: final release. The point of alpha is not to provide a stable platform but initial point for the release and flush out bugs by expanding the user base. It's not a production release. Exactly. Requiring a working bug tracker. Postponing the release for a week if I can't get in touch with the guys early enough is the logical thing in my opinion. We do however have a 5.4RC out there for some reason.. It looks like we could have some working tracker (even though without all the old stuff back yet) very soon - at least so it seems from the info that I've got - so provided that we already delayed it a number of times, I'd rather have it out sooner. We could though advance the next alpha - say, to Thursday July 21, if we are settled on Thursday being the Release Day :) - which is not that far out, and will have all the new goodies. I'd rather have something out to get the release process finally officially kick off than to wait again. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, Jun 28, 2011 at 21:59, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/28/11 12:49 PM, Hannes Magnusson wrote: On Tue, Jun 28, 2011 at 21:00, Stas Malyshevsmalys...@sugarcrm.com wrote: final release. The point of alpha is not to provide a stable platform but initial point for the release and flush out bugs by expanding the user base. It's not a production release. Exactly. Requiring a working bug tracker. Postponing the release for a week if I can't get in touch with the guys early enough is the logical thing in my opinion. We do however have a 5.4RC out there for some reason.. That was ofcourse supposed to say 5.3RC :) It looks like we could have some working tracker (even though without all the old stuff back yet) very soon - at least so it seems from the info that I've got - so provided that we already delayed it a number of times, I'd rather have it out sooner. We could though advance the next alpha - say, to Hang on.. wait what? So Pierres weird threats on IRC weren't silly jokes? Heck, we could apt-get install bugzilla on a random mirror if you just want some bug tracker database to ignore and have something. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
Hang on.. wait what? So Pierres weird threats on IRC weren't silly jokes? Heck, we could apt-get install bugzilla on a random mirror if you just want some bug tracker database to ignore and have something. merging the new bugs would be a little more work though. and it would be weird that we change to bugzilla, then back to the old bugtracker when we get the backup from the hoster. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 alpha
On Tue, Jun 28, 2011 at 10:06 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Hang on.. wait what? So Pierres weird threats on IRC weren't silly jokes? Heck, we could apt-get install bugzilla on a random mirror if you just want some bug tracker database to ignore and have something. Hannes, with all respects to your work, such comments are not welcome in this list. As I told you, it is not me, but the release managers who decide when a release can be done. And despite our efforts to get the situation around bugs.php.net sorted out, nothing, absolutely nothing happened in two weeks. We bring it back and we will restore the existing data as soon as we have the backups. See my other mail for the details. -- 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
[PHP-DEV] 5.4 alpha
Hi! Since we've got voting on the process RFCs finally going on, after much deliberation we've decided it'd be best to let the votes finish before the first official 5.4 release. Thus, we decided to postpone 5.4 alpha 1 until June 28th (next Tuesday). The updated schedule is at https://wiki.php.net/todo/php54 , please check out. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote: I could not disagree more. I think one of the key lessons we should have learned out of the whole 6.0 saga was that release early, release often is a good thing I will no support the release of trunk overly actively as long as the type hints are as they are but on a general note: Yes. Release early, release often is a good thing. What I'd also like is to have a Ubuntu-like support model. Where we have one LTS (long term supported) version (now for instance 5.3) which will get bug fixes for quite some time and an early access version (5.4) which will receive updates until the next early access (5.5) is there. Reasons: * Give people early access to features * Motivate developers as their additions are in a reachable future * Give users the chance to stay on the LTS version without having to do the full update on every release * Reduce the number of changes in bugfix releases the whole idea in ASCII art: Version Time - 5.3 + 5.4 |* 5.5 ||* 5.6 |||* 6.0 |||| 6.1 |||||* |||||| |||||^ Release date 6.1.0 ||||^ Release 6.0.0, 5.3 goes to extended support (security only) |||^ Release 5.6.0, 5.3 stays in support, 5.5 EOL ||^ Release 5.5.0, 5.3 stays in support, 5.4 EOL |^ Release 5.4.0, 5.3 stays in support ^ now So we'd always have three branches, while two only receive bug fixes, plus one branch for the next milestone. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
Am 10.08.2010 10:45, schrieb Johannes Schlüter: So we'd always have three branches, while two only receive bug fixes, plus one branch for the next milestone. +1 -- 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] 5.4 Alpha?
Sebastian Bergmann wrote: So we'd always have three branches, while two only receive bug fixes, plus one branch for the next milestone. +1 And currently 5.2.x is still the preferred base as there is still a lot of third party stuff that has to make the transition to 5.3.x ... Pushing new stuff through is all very well, but some core code bases are 15 years old and while they can remain on older versions of PHP, an LTS build would be very helpful ... one can target that for upgrading old code and then move forward if needed. Heck some projects have only just closed down PHP4 support on their trunk ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
2010/8/10 Johannes Schlüter johan...@php.net: Yes. Release early, release often is a good thing. What I'd also like is to have a Ubuntu-like support model. Where we have one LTS (long term supported) version (now for instance 5.3) which will get bug fixes for quite some time and an early access version (5.4) which will receive updates until the next early access (5.5) is there. I'm happy with the three branches idea, but I do have some concerns about an LTS model: – The LTS branch is going to become more and more difficult to backport fixes to as it diverges from the other two branches, and I can see developers not bothering after a certain point, which may be counter productive. – Documenting how functionality changes from version to version in the manual is already a weak point, judging by some of the bugs and feedback we get: users don't always grok the version bylines and change log tables in the function reference as it is, and that's with a more closely aligned set of active branches. We might end up needing to rethink how we structure the manual by looking at something like the Python approach of having separate manuals for separate versions, which would require a not-insignificant amount of work. – It might be hard to communicate why 5.4 (in the example you included) becomes end of lifed while 5.3 lives on. I guess that's no different to Ubuntu, though. – Will downstream distributors want to ship non-LTS versions? This might actually reduce the amount of useful feedback we get for (again, using your example) 5.4, 5.5 and 5.6 releases, which might not be a great thing for the stability of the next LTS (6.0) release. So we'd always have three branches, while two only receive bug fixes, plus one branch for the next milestone. As I said, I have no qualms with this, particularly in light of some of the articles that have been doing the rounds about 5.2's end of lifing.* Under this system, and without an LTS structure, our current situation would be a bit different, with both 5.2 and 5.3 getting bug fixes until trunk is released (at which point 5.2 would be EOL), which I think would suit users a bit better. Adam * Yes, I know it's not actually EOL, but that's been another communication challenge. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2010 11:25 AM, Adam Harvey wrote: We might end up needing to rethink how we structure the manual by looking at something like the Python approach of having separate manuals for separate versions, which would require a not-insignificant amount of work. As an PHP developer: Providing manuals based on version sounds like a good idea. But I'm not sure about the amount of additional work involved and the willingness of docs contributors to do this.. – Will downstream distributors want to ship non-LTS versions? As Gentoo downstream: yes, sure. Not so sure about Ubuntu and other binary-based distributions, as long as you don't fit into their LTS release cycle. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxhHhkACgkQfNMcoUhJ7GxubgCZAe5cjy3COOX0/y5ChpqoMaxd ZnMAnigNMR0CbKHL/Ky7EkM2EvgMioyJ =AEUz -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
hi, On Tue, Aug 10, 2010 at 4:19 AM, Adam Harvey ahar...@php.net wrote: On 10 August 2010 07:28, Pierre Joye pierre@gmail.com wrote: On Mon, Aug 9, 2010 at 11:56 PM, Kalle Sommer Nielsen ka...@php.net wrote: With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. Huge -1 here. We are light years away to even be able to define what will be php-next. Let discuss that September, at the soonest. I could not disagree more. I think one of the key lessons we should have learned out of the whole 6.0 saga was that release early, release often is a good thing The key lesson of PHP 6 is that the lack of consensus, decision process, design, clear roadmap and release process leads to chaos, frustration and dead cows. But from a technical point of view, yes, we have almost every thing to begin to think about php-next. 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] 5.4 Alpha?
On Tue, 2010-08-10 at 17:25 +0800, Adam Harvey wrote: – The LTS branch is going to become more and more difficult to backport fixes to as it diverges from the other two branches, and I can see developers not bothering after a certain point, which may be counter productive. Except for things like the Unicode branch our code base is quite stable in most places. – Documenting how functionality changes from version to version in the manual is already a weak point, judging by some of the bugs and feedback we get: users don't always grok the version bylines and change log tables in the function reference as it is, and that's with a more closely aligned set of active branches. We might end up needing to rethink how we structure the manual by looking at something like the Python approach of having separate manuals for separate versions, which would require a not-insignificant amount of work. In the LTS the functionality shouldn't change (having shorter cycles even between other bug fix releases) Yes there are exceptions where a needed bug fix has an effect, but documenting this should be solvable. – It might be hard to communicate why 5.4 (in the example you included) becomes end of lifed while 5.3 lives on. I guess that's no different to Ubuntu, though. Better naming than simply 5.3, 5.4 ... might help. But should be solvable. – Will downstream distributors want to ship non-LTS versions? This might actually reduce the amount of useful feedback we get for (again, using your example) 5.4, 5.5 and 5.6 releases, which might not be a great thing for the stability of the next LTS (6.0) release. Distributors should be able to distribute two versions. Some do/did with PHP 4 and PHP 5. And I prefer distributions offering the bug fix releases for the LTS version over a heavily patched outdated 5.1.6 like RedHat does. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
On Tue, Aug 10, 2010 at 11:38, Matti Bickel m...@rateu.de wrote: As an PHP developer: Providing manuals based on version sounds like a good idea. But I'm not sure about the amount of additional work involved and the willingness of docs contributors to do this.. Thats a heckofamore work then we have man power for. The manual have explicit inline notes about every change, and features only available in certain versions are clearly noted. I really don't see the usecase for version specific manuals - you should be aware of the changes, past and future, so you can make up your own mind on which version your application should run - and be able to write future compatible code. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
2010/8/10 Johannes Schlüter johan...@php.net: On Tue, 2010-08-10 at 17:25 +0800, Adam Harvey wrote: – The LTS branch is going to become more and more difficult to backport fixes to as it diverges from the other two branches, and I can see developers not bothering after a certain point, which may be counter productive. Except for things like the Unicode branch our code base is quite stable in most places. Speaking of unicode, did we ever get the intl based mbstring patch into trunk? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2010 11:47 AM, Hannes Magnusson wrote: On Tue, Aug 10, 2010 at 11:38, Matti Bickel m...@rateu.de wrote: As an PHP developer: Providing manuals based on version sounds like a good idea. But I'm not sure about the amount of additional work involved and the willingness of docs contributors to do this.. Thats a heckofamore work then we have man power for. Okay, point taken. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxhIjMACgkQfNMcoUhJ7GzQzwCgkHNgc0ea0r6j1VUtWYaCGNqF VE4An3lSzlseFi3FIPDMM2A6avG2Bj2y =RwyU -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
On Tue, 10 Aug 2010, Johannes Schlüter wrote: So we'd always have three branches, while two only receive bug fixes, plus one branch for the next milestone. That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS idea is way too optimistic. I really don't care about porting bug fixes back to 5.2 because it is *four* years old. PHP 5.3 has been out for a year. Right now there are not many API differences, but it *does* cost extra time to maintain. Time we should rather spend on getting new things out. Leave the 5.2 support to the distributions! 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] 5.4 Alpha?
On Mon, 9 Aug 2010, Kalle Sommer Nielsen wrote: With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. I'd say: let's do 5.4-alpha! There's plenty of cool stuff in trunk. 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] 5.4 Alpha?
2010/8/10 Derick Rethans der...@php.net: That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS idea is way too optimistic. I really don't care about porting bug fixes back to 5.2 because it is *four* years old. PHP 5.3 has been out for a year. Right now there are not many API differences, but it *does* cost extra time to maintain. Time we should rather spend on getting new things out. Leave the 5.2 support to the distributions! In terms of backporting fixes (talking more generally about the three branch model and not so much about 5.2 in particular), between PHP and other projects I'm involved with, I'm acutely aware of the pain there. Honestly, though, I'm not entirely comfortable just leaving it up to distributions: plenty of people run hand-built versions of PHP, and testing large codebases with new branches of PHP isn't always as quick a process as it should be. Or, put another way, just because I'm lucky enough to be able to run my code on the bleeding edge doesn't mean I don't feel a little bit obligated towards people who aren't that lucky. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
2010/8/10 Lukas Kahwe Smith m...@pooteeweet.org: On 10.08.2010, at 10:45, Johannes Schlüter wrote: On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote: Yes. Release early, release often is a good thing. What I'd also like is to have a Ubuntu-like support model. Where we have one LTS (long term supported) version (now for instance 5.3) which will get bug fixes for quite some time and an early access version (5.4) which will receive updates until the next early access (5.5) is there. Reasons: * Give people early access to features * Motivate developers as their additions are in a reachable future * Give users the chance to stay on the LTS version without having to do the full update on every release * Reduce the number of changes in bugfix releases Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). We have to provide a well defined life cycle for our releases. The way we do it now is not good, not for linux distros and not for developers. It is impossible to get a mid term visibility. 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] 5.4 Alpha?
On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote: Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). Well, I don't see it as loong term support, but rather as way to enable quick feature cycles, so that feature releases can move faster than anybody can upgrade to them (ok, that's a bit too fast the, but hope you get the point), while new features can get in production sooner, where wanted. We could also use the names feature preview release and stable release(=lts) ... which would bring us close to MySQL's model and their confusing version numbering (MySQL 5.1 is the stable there, then MySQL 5.4 was announced as preview, now MySQL 5.5 is the current preview release, neither 5.4 nor 5.5 are stable, GA, though) johanne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
On 10.08.2010, at 10:45, Johannes Schlüter wrote: On Tue, 2010-08-10 at 10:19 +0800, Adam Harvey wrote: Yes. Release early, release often is a good thing. What I'd also like is to have a Ubuntu-like support model. Where we have one LTS (long term supported) version (now for instance 5.3) which will get bug fixes for quite some time and an early access version (5.4) which will receive updates until the next early access (5.5) is there. Reasons: * Give people early access to features * Motivate developers as their additions are in a reachable future * Give users the chance to stay on the LTS version without having to do the full update on every release * Reduce the number of changes in bugfix releases Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). 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] 5.4 Alpha?
2010/8/10 Johannes Schlüter johan...@schlueters.de On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote: Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). Well, I don't see it as loong term support, but rather as way to enable quick feature cycles, so that feature releases can move faster than anybody can upgrade to them (ok, that's a bit too fast the, but hope you get the point), while new features can get in production sooner, where wanted. We could also use the names feature preview release and stable release(=lts) ... which would bring us close to MySQL's model and their confusing version numbering (MySQL 5.1 is the stable there, then MySQL 5.4 was announced as preview, now MySQL 5.5 is the current preview release, neither 5.4 nor 5.5 are stable, GA, though) johanne they started to use milestone release-s. http://dev.mysql.com/tech-resources/articles/mysql-release-model.html http://dev.mysql.com/tech-resources/articles/mysql-release-model.html Tyrael
[PHP-DEV] Version management (was: Re: [PHP-DEV] 5.4 Alpha?)
On Tue, 10 Aug 2010, Johannes Schlüter wrote: On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote: Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). Well, I don't see it as loong term support, but Using LTS as a term confused me on that one :P rather as way to enable quick feature cycles, so that feature releases can move faster than anybody can upgrade to them (ok, that's a bit too fast the, but hope you get the point), while new features can get in production sooner, where wanted. We could also use the names feature preview release and stable release(=lts) ... which would bring us close to MySQL's model and their confusing version numbering (MySQL 5.1 is the stable there, then MySQL 5.4 was announced as preview, now MySQL 5.5 is the current preview release, neither 5.4 nor 5.5 are stable, GA, though) I still don't think this is a good idea though. That would me we have (as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you (at that point) like supporting a 4/5 year old version? Do you hvae that much spare time? I think our current way work pretty well. There is 5.2 which is security-fix supported, 5.3 that is supported and trunk/5.4 that's on the way to alpha. 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] Version management (was: Re: [PHP-DEV] 5.4 Alpha?)
2010/8/10 Derick Rethans der...@php.net On Tue, 10 Aug 2010, Johannes Schlüter wrote: On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote: Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). Well, I don't see it as loong term support, but Using LTS as a term confused me on that one :P rather as way to enable quick feature cycles, so that feature releases can move faster than anybody can upgrade to them (ok, that's a bit too fast the, but hope you get the point), while new features can get in production sooner, where wanted. We could also use the names feature preview release and stable release(=lts) ... which would bring us close to MySQL's model and their confusing version numbering (MySQL 5.1 is the stable there, then MySQL 5.4 was announced as preview, now MySQL 5.5 is the current preview release, neither 5.4 nor 5.5 are stable, GA, though) I still don't think this is a good idea though. That would me we have (as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you (at that point) like supporting a 4/5 year old version? Do you hvae that much spare time? I think our current way work pretty well. There is 5.2 which is security-fix supported, 5.3 that is supported and trunk/5.4 that's on the way to alpha. Derick From the ubuntu wiki: A new LTS version is usually released every 2 years. With the Long Term Support (LTS) version you get 3 years support on Ubuntu Desktop, and 5 years on Ubuntu Server. There is no extra fee for the LTS version; we make our very best work available to everyone on the same free terms. Upgrades to new versions of Ubuntu are and always will be free of charge. So with this release policy comes the following terms: - the releases coming in a timely manner. - normal release gets support until the next release comes out. - an LTS release gets support until a pre-defined time interval(and we promise we will release the next LTS until that time). - you have an upgrade-path from a version to the next one. - you have an upgrade-path from an lts version to the next lts. we could change the interval-s to suit our needs, but with this policy, the early-adopters could use and test the new features earlier, but the lazy devs are allowed to upgrade only with the EOL of the LTS. with the new approach we could release a new major version much faster and smaller changeset. I would suggest the 5.3 branch for the first LTS what are your thoughts about the optimal timeframe for a normal/LTS php release? I would prefer 6-12 months for a release, and 2-3 years for an LTS (this is why we shouldn't start the LTS with the already old 5.2 branch ) Tyrael
[PHP-DEV] Re: Version management (was: Re: [PHP-DEV] 5.4 Alpha?)
On Tue, 2010-08-10 at 16:14 +0100, Derick Rethans wrote: On Tue, 10 Aug 2010, Johannes Schlüter wrote: On Tue, 2010-08-10 at 16:20 +0200, Lukas Kahwe Smith wrote: Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others). Well, I don't see it as loong term support, but Using LTS as a term confused me on that one :P Yeah, I didn't focus on the release earl, often fact enough. rather as way to enable quick feature cycles, so that feature releases can move faster than anybody can upgrade to them (ok, that's a bit too fast the, but hope you get the point), while new features can get in production sooner, where wanted. We could also use the names feature preview release and stable release(=lts) ... which would bring us close to MySQL's model and their confusing version numbering (MySQL 5.1 is the stable there, then MySQL 5.4 was announced as preview, now MySQL 5.5 is the current preview release, neither 5.4 nor 5.5 are stable, GA, though) I still don't think this is a good idea though. That would me we have (as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you (at that point) like supporting a 4/5 year old version? Do you hvae that much spare time? I think our current way work pretty well. There is 5.2 which is security-fix supported, 5.3 that is supported and trunk/5.4 that's on the way to alpha. Well, maintaining them becomes simpler if we change less features. Like adding a new SAPI in x.y.3 and lots of stuff in x.y.2. And for doing this we need shorter cycles. There is always small stuff, like simple functions, which misses a .0 release. Now committing them to trunk means they appear for earl adapters for the next version 1.5 to 2 years later. For the developers it is is stupid to hold a small harmless addition back so what are we doing - we're backporting stuff. Tons of stuff. If we shorten the cycle by which features become available in a stable/feature preview/... version we do have to care less about backporting, which makes handling of the released branches simpler. On the other side short cycles are bad for getting people to migrate, that's why there are longer supported releases. Now having distributors doing the backporting is nice for our workload (distributor package - bogus bug report) but then one has to choose a distribution where you like the environment (what inisystem, what packagemanager etc.) and which doesn't break the timezone database or something else. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.4 Alpha?
On Tue, Aug 10 2010, Derick Rethans wrote On Mon, 9 Aug 2010, Kalle Sommer Nielsen wrote: With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. I'd say: let's do 5.4-alpha! There's plenty of cool stuff in trunk. Absolutely. Humbly, if the release early, release often mantra is to be [re-]embraced, I'd say start right now. Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4 Alpha?
Greetings geeks With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 Alpha?
hi, Huge -1 here. We are light years away to even be able to define what will be php-next. Let discuss that September, at the soonest. Cheers, On Mon, Aug 9, 2010 at 11:56 PM, Kalle Sommer Nielsen ka...@php.net wrote: Greetings geeks With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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
答复: [PHP-DEV] 5.4 Alpha?
http://news.php.net/php.internals/49186 I hope 5.4 beta complete support LFS. -邮件原件- 发件人: kalle@gmail.com [mailto:kalle@gmail.com] 代表 Kalle Sommer Nielsen 发送时间: 2010年8月10日 5:56 收件人: Internals 主题: [PHP-DEV] 5.4 Alpha? Greetings geeks With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. -- regards, Kalle Sommer Nielsen ka...@php.net -- 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] 5.4 Alpha?
On 10 August 2010 07:28, Pierre Joye pierre@gmail.com wrote: On Mon, Aug 9, 2010 at 11:56 PM, Kalle Sommer Nielsen ka...@php.net wrote: With the recent additions to 5.4, aren't we getting closer to have a public alpha release, or just a development test as we have many great additions and changes to the current trunk or atleast set up some sort of roadmap for what we all like to have in 5.4, or be that 6.0 as thats yet another thing we should get settled soonish. Huge -1 here. We are light years away to even be able to define what will be php-next. Let discuss that September, at the soonest. I could not disagree more. I think one of the key lessons we should have learned out of the whole 6.0 saga was that release early, release often is a good thing, and I don't see much on the RFC list or that's been discussed recently on Internals that's going to be significantly advanced if we leave even discussing it another month or more. I think it's time to make a few decisions on what's in and what's out and move on. Trunk doesn't seem to be in a bad state, all told, so I'd love to see a 5.3+δ alpha next month (presumably towards the end of it) — that doesn't imply a feature freeze, or remove the possibility to change things later, but it does tell developers that we're pretty serious about what's in trunk, and that we want people to start playing with some of the new features like traits to see how it effects them and start reporting bugs. Bear in mind, too, that even with a September alpha, we'd still be looking at a release early next year at the earliest. Even on the quickest timeline I could imagine — a couple of alphas, maybe a first beta on the run down to Christmas, another beta or two early next year, then some RCs — I can't see a stable release until autumn (OK, spring for most of you: March-May) next year, which would be the best part of two years after 5.3.0. Remember, that's assuming we move fast, and history's against us there. :) Adam, who looks forward to getting flamed on IRC later for writing another long screed. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
