On Thu, Dec 2, 2010 at 11:01 AM, Christopher Jones
wrote:
>
>
> On 11/26/2010 11:15 AM, Zeev Suraski wrote:
>>
>> 3. The motivation to skip 6 doesn't stem from marketing at all. The main
>> motivation is that there's a VERY concrete perception amongst many users
>> about what PHP 6 is. It's unli
On 2 Dec 2010, at 19:46, "Christopher Jones"
wrote:
>
>
> On 12/02/2010 11:23 AM, James Butler wrote:
>> Following that logic, they will expect the next major version number,
>> whatever it is, to have Unicode. Nothing can be done about that apart from
>> telling the world it won't, includ
On 12/02/2010 11:23 AM, James Butler wrote:
Following that logic, they will expect the next major version number, whatever
it is, to have Unicode. Nothing can be done about that apart from telling the
world it won't, including it in, or let them find out for themselves...
If we decide the
Following that logic, they will expect the next major version number, whatever
it is, to have Unicode. Nothing can be done about that apart from telling the
world it won't, including it in, or let them find out for themselves...
--
James Butler
Sent from my iPhone
On 2 Dec 2010, at 19:02, "Chri
On 11/26/2010 11:15 AM, Zeev Suraski wrote:
3. The motivation to skip 6 doesn't stem from marketing at all. The main
motivation is that there's a VERY concrete perception amongst many users about
what PHP 6 is. It's unlikely that PHP 6 will actually be that. Skipping this
version makes pe
On Sat, 2010-11-27 at 11:58 -0500, Matthew Weier O'Phinney wrote:
> On 2010-11-26, Pierre Joye wrote:
> > On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote:
> > > 3. The motivation to skip 6 doesn't stem from marketing at all. The
> > > main motivation is that there's a VERY concrete perceptio
On Sat, Nov 27, 2010 at 5:58 PM, Matthew Weier O'Phinney
wrote:
> On 2010-11-26, Pierre Joye wrote:
>> On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote:
>> > 3. The motivation to skip 6 doesn't stem from marketing at all. The
>> > main motivation is that there's a VERY concrete perception am
On 2010-11-26, Pierre Joye wrote:
> On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote:
> > 3. The motivation to skip 6 doesn't stem from marketing at all. The
> > main motivation is that there's a VERY concrete perception amongst
> > many users about what PHP 6 is.
>
> Leaving the very small c
On 11/26/10 12:58 PM, Zeev Suraski wrote:
>> Only that it has no technical or features-
>> wise reasons to do so
>
> Substantial engine level improvements and a couple of new language level
> features (it's pushing it a bit, I agree, but not that much)
I think the next major version should be us
On Fri, Nov 26, 2010 at 2:27 PM, Pierre Joye wrote:
> On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote:
>
> > 3. The motivation to skip 6 doesn't stem from marketing at all. The main
> motivation is that there's a VERY concrete perception amongst many users
> about what PHP 6 is.
>
> Leaving
Zeev Suraski wrote:
that's the crowd I referenced to. The users I discuss too, in locale conference,
> UG, enterprises, etc. never heard or only vaguely about php6. Or they heard
> about it while seeing a book called "PHP 6 and mysql 6" or something stupid
> like that;).
I've yet to meet some
> that's the crowd I referenced to. The users I discuss too, in locale
> conference,
> UG, enterprises, etc. never heard or only vaguely about php6. Or they heard
> about it while seeing a book called "PHP 6 and mysql 6" or something stupid
> like that ;).
I've yet to meet someone in the last few
On Fri, Nov 26, 2010 at 9:58 PM, Zeev Suraski wrote:
> I disagree. Google for "PHP 6". I've received tons of questions about it
> from non-core-community attendees to conferences.
that's the crowd I referenced to. The users I discuss too, in locale
conference, UG, enterprises, etc. never hear
> Only that it has no technical or features-
> wise reasons to do so
Substantial engine level improvements and a couple of new language level
features (it's pushing it a bit, I agree, but not that much)
> but brings its lots of risks with it.
I fail to see how changing a version number brings a
On Fri, Nov 26, 2010 at 8:15 PM, Zeev Suraski wrote:
> I'll begin again by saying I don't feel strongly about renaming 5.4 as 7.0,
> but there are some important points worth bringing up:
>
> 1. The motivation for changing major version numbers was *never* BC breakage.
> It was substantial lan
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Friday, November 26, 2010 7:21 PM
> To: Zeev Suraski
> Cc: Ilia Alshanetsky; Johannes Schlüter; Andi Gutmans; Jani Taskinen;
> da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hol
hanetsky
>>> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen;
>>> da...@php.net; PHP Internals
>>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>>
>>> That can always be done later.
>>
>> Why do it later if we could do it now? :)
>>
askinen;
>> da...@php.net; PHP Internals
>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>
>> That can always be done later.
>
> Why do it later if we could do it now? :)
>
> Can you share some of the major things you think would constitute a stronger
> reason
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Friday, November 26, 2010 12:00 PM
> To: Kalle Sommer Nielsen
> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen;
> da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hol
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Friday, November 26, 2010 3:03 AM
> To: Ilia Alshanetsky
> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen;
> da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hold
On Thu, 25 Nov 2010, Pierre Joye wrote:
> On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans wrote:
>
> >> This doesn't seem the ideal time to introduce a new toolchain, so
> >> sticking with SVN, we should maintain 4 branches, 5.2 (security only),
> >> 5.3 (bug fixes + security), 5.4 (agreed upon
On Fri, 26 Nov 2010, Kalle Sommer Nielsen wrote:
> 2010/11/25 Zeev Suraski :
> > I think that skipping to a major version is a good idea.
> >
> > Two key reasons I think that:
> >
> > 1. It'll help us break the evil spell of the 6 version number.
> > Honestly, I'm not so certain we'll have majo
Hi
2010/11/25 Zeev Suraski :
> I think that skipping to a major version is a good idea.
>
> Two key reasons I think that:
>
> 1. It'll help us break the evil spell of the 6 version number. Honestly,
> I'm not so certain we'll have major engine rewrites the size of what we've
> seen in PHP 3/4/
That can always be done later. Even if I don't think users care much
about 6 or 7 being the version for the next major release. However for
what I can read or hear, they care about traits and many of the points
described in the RFC.
Maybe we could focus on getting the RFC sorted out and figure out
I don't think the version # makes that much of a difference, but
rather what is in it. That said, people have made a good point that
jumping to something like 7, would allow us to skip the baggage
associated with PHP6, which seems like a fairly compelling argument to
me.
On Thu, Nov 25, 2010 at 6:
On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski wrote:
> I think that skipping to a major version is a good idea.
It is appealing but not a good idea. I think it is better to get 5.4
with the features we like in it and then consider a major version.
There are quite a few things that we could add o
ng time (and I do think it actually reflects
badly on the way the language is perceived to some degree).
My 2c.
Zeev
-Original Message- From: Johannes Schlüter
[mailto:johan...@schlueters.de] Sent: Thursday, November 25, 2010
7:55 PM To: Andi Gutmans Cc: Jani Taskinen; da...@php.net; PHP
I
On Thu, Nov 25, 2010 at 16:56, Zeev Suraski wrote:
>
> Can't say I feel strongly about it, but I have a feeling that unless we
> change our versioning scheme a slight bit, we'll be stuck in the 5.x realm
> for a very long time (and I do think it actually reflects badly on the way
> the language
ly reflects badly on the way the language is
perceived to some degree).
My 2c.
Zeev
> -Original Message-
> From: Johannes Schlüter [mailto:johan...@schlueters.de]
> Sent: Thursday, November 25, 2010 7:55 PM
> To: Andi Gutmans
> Cc: Jani Taskinen; da...@php.net; PHP Internal
On Thu, 2010-11-25 at 10:25 -0800, Rasmus Lerdorf wrote:
> We also need that non-null zend_parse_parameters type implemented to
> clean up the null-byte poisoning fixes in 5.3.
Recently there was an off-list discussion about adding support for
accepting non-empty strings only via zend_parse_param
On 11/25/10 11:01 AM, Pierre Joye wrote:
> I noticed it where functions accepts a path, do some checks (exists,
> writable, etc.), resolves paths, etc. and then similar ops are done
> again in a couple of places before we call the low level functions,
> like in stream, tsrm for example, or extensi
Thursday, November 25, 2010 10:26 AM
>>>> To: Ilia Alshanetsky
>>>> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP
>>>> Internals
>>>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>>>
>>>> We also need tha
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Thursday, November 25, 2010 10:46 AM
> To: Andi Gutmans
> Cc: Ilia Alshanetsky; Johannes Schlüter; da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>
> > Yes
t;> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP
>>> Internals
>>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>>
>>> We also need that non-null zend_parse_parameters type implemented to clean
>>> up the null-byte poisoning fixes
HP
>> Internals
>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>
>> We also need that non-null zend_parse_parameters type implemented to clean
>> up the null-byte poisoning fixes in 5.3. I can't see this slowing us down
>> much as
>> it is pretty trivial.
a...@php.net; PHP
>> Internals
>> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>>
>> We also need that non-null zend_parse_parameters type implemented to clean
>> up the null-byte poisoning fixes in 5.3. I can't see this slowing us down
>> much as
>> it is
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Thursday, November 25, 2010 10:26 AM
> To: Ilia Alshanetsky
> Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP
> Internals
> Subject: Re: [PHP-DEV] Re: Hold off 5.4
&
On 11/25/10 9:44 AM, Ilia Alshanetsky wrote:
>> Looking through trunk I think we are in pretty good shape. I don't
>> think cherry-picking and branch merging is an issue at this point. A
>> 5.4 with the performance improvements, Traits, minus the type hinting
>> breakage is something we can get o
On Thu, 2010-11-25 at 17:39 +, Andi Gutmans wrote:
> This is no different in the Java world, C++ as it matured or some
> other technologies.
Java is currently at 1.6. (and 6 in Marketing) :-)
C++ went from ISO/IEC 14882:1998 to ISO/IEC 14882:2003 and is waiting
for C++0x, whatever the actual n
2010/11/25 Andi Gutmans :
>> -Original Message-
>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
>> Sent: Thursday, November 25, 2010 9:27 AM
>> To: Johannes Schlüter
>> Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals
>> Sub
> Looking through trunk I think we are in pretty good shape. I don't
> think cherry-picking and branch merging is an issue at this point. A
> 5.4 with the performance improvements, Traits, minus the type hinting
> breakage is something we can get out pretty quickly without causing any
> sort of P
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Thursday, November 25, 2010 9:27 AM
> To: Johannes Schlüter
> Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>
> Looking through
> -Original Message-
> From: Johannes Schlüter [mailto:johan...@schlueters.de]
> Sent: Thursday, November 25, 2010 9:21 AM
> To: Andi Gutmans
> Cc: Jani Taskinen; da...@php.net; PHP Internals
> Subject: RE: [PHP-DEV] Re: Hold off 5.4
>
> On Thu, 2010-11-25 at 1
hi Rasmus,
2010/11/25 Rasmus Lerdorf :
> On 11/25/10 9:20 AM, Johannes Schlüter wrote:
>> On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote:
>>> For what it's worth the changes we've made in the Zend Engine around
>>> performance and memory use could warrant a major version. Every major
>>> ve
On 11/25/10 9:20 AM, Johannes Schlüter wrote:
> On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote:
>> For what it's worth the changes we've made in the Zend Engine around
>> performance and memory use could warrant a major version. Every major
>> version of PHP in the past has been driven forem
On Thu, Nov 25, 2010 at 6:11 PM, Andi Gutmans wrote:
>> -Original Message-
>> From: Jani Taskinen [mailto:jani.taski...@iki.fi]
>> Sent: Thursday, November 25, 2010 12:25 AM
>> To: da...@php.net
>> Cc: PHP Internals
>> Subject: Re: [PHP-DEV] Re: Hold
On Thu, 2010-11-25 at 15:11 +, Derick Rethans wrote:
>
> Yes, I also think trunk should be 5.4. It's not the most ideal thing
> though, but something we'll have to live with. It's going to be a lot
> less of a hassle than cherry picking trunk's features and graft them
> onto 5.3.
Agreed.
On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote:
> For what it's worth the changes we've made in the Zend Engine around
> performance and memory use could warrant a major version. Every major
> version of PHP in the past has been driven foremost by major engine
> overhauls.
Yes, larger chang
> -Original Message-
> From: Jani Taskinen [mailto:jani.taski...@iki.fi]
> Sent: Thursday, November 25, 2010 12:25 AM
> To: da...@php.net
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] Re: Hold off 5.4
>
> Who says it has to be 5.4? People seem to be a bit fixated
On Nov 25, 2010, at 9:05 AM, Derick Rethans wrote:
> On Thu, 25 Nov 2010, Davey Shafik wrote:
>
>> The goal then was to essentially take the 5.3 branch, create a 5.4
>> branch, cherry pick commits to trunk and apply them to the 5.4 branch
>> and end up with a stable build. Unfortunately, subve
On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans wrote:
>> This doesn't seem the ideal time to introduce a new toolchain, so
>> sticking with SVN, we should maintain 4 branches, 5.2 (security only),
>> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC
>> breaks), 6.0 (BC breaks).
>
On Thu, 25 Nov 2010, Gustavo Lopes wrote:
> On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans wrote:
>
> > On Thu, 25 Nov 2010, Davey Shafik wrote:
> >
> > > The goal then was to essentially take the 5.3 branch, create a 5.4
> > > branch, cherry pick commits to trunk and apply them to the 5.4
On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans wrote:
On Thu, 25 Nov 2010, Davey Shafik wrote:
The goal then was to essentially take the 5.3 branch, create a 5.4
branch, cherry pick commits to trunk and apply them to the 5.4 branch
and end up with a stable build. Unfortunately, subversion
On Thu, 25 Nov 2010, Davey Shafik wrote:
> The goal then was to essentially take the 5.3 branch, create a 5.4
> branch, cherry pick commits to trunk and apply them to the 5.4 branch
> and end up with a stable build. Unfortunately, subversion merging
> sucks.
This has nothing to do with any sor
May I ask not to begin with that again? The php 2034 thing?
Let sort out what has to be sorted out, like the current proposals. In
the short term, a 5.x (with BC) is what users and developers are
looking for. We can then begin to think about the next big step.
On Thu, Nov 25, 2010 at 1:58 PM, Jam
Slightly brambly thoughts...
I think (imho) the PHP6 hype in user land died down long ago after it became
obvious it wouldn't materialise any time soon. It would be nice to see 6 to
appear if only to break the (apparent) deadlock that the Unicode stuff brought
on(I realise this is not enough jus
On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:
> 2010/11/25 Jani Taskinen :
>> Who says it has to be 5.4? People seem to be a bit fixated on the version
>> there.
>
> I'd like to know too...
>
>> Major BC breaks just means the version released from trunk is 6.0. And it's
>> just a number
2010/11/25 Jani Taskinen :
> Who says it has to be 5.4? People seem to be a bit fixated on the version
> there.
I'd like to know too...
> Major BC breaks just means the version released from trunk is 6.0. And it's
> just a number. Big number, but still just a number.
Well, such a change tends
On 2010-11-23, Felipe Pena wrote:
> --001636eef065b3eaf30495ae5198
> Content-Type: text/plain; charset=UTF-8
>
> Given the current state of trunk, I think 5.4 release process should
> not begin tomorrow (alpha or whatever other status). There are
> numerous identified issues that we need to fix be
Who says it has to be 5.4? People seem to be a bit fixated on the version
there.
Major BC breaks just means the version released from trunk is 6.0. And it's
just a number. Big number, but still just a number.
Merging (by and or by magic :) features into branch created from 5.3 just
sounds like
2010/11/25 Davey Shafik :
>
> On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
>
>> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote:
>>> On 11/23/2010 02:30 AM, Felipe Pena wrote:
>>
5.4 should be hold off until we solved the listed issues and the
release management RFC gets discus
On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote:
>> On 11/23/2010 02:30 AM, Felipe Pena wrote:
>
>>> 5.4 should be hold off until we solved the listed issues and the
>>> release management RFC gets discussed and hopefully approved.
The r
On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner wrote:
> On 11/23/2010 02:30 AM, Felipe Pena wrote:
>> 5.4 should be hold off until we solved the listed issues and the
>> release management RFC gets discussed and hopefully approved.
>
> +1
+1 here too.
--
Pierre
@pierrejoye | http://blog.the
On 11/23/2010 02:30 AM, Felipe Pena wrote:
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
...
We also have
64 matches
Mail list logo
