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
hi Andi,
On Thu, Nov 25, 2010 at 7:42 AM, Andi Gutmans a...@zend.com wrote:
I agree with that. More structure and predictability will be very valuable to
the project. We created a lot of structure in Zend Framework and it has
really paid off.
Btw, we don't have to look far. Just the change
On 2010-11-25, Pierre Joye pierre@gmail.com wrote:
hi,
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use
On Wed, 2010-11-24 at 21:46 -0800, Stas Malyshev wrote:
However, there are a lot of
practical challenges (auth, etc.) that need to be solved.
I think one of the biggest issues is PHP extension handling. All ways
for moving extensions in/out while keeping history are annoying. Doing
all in
I really like Git (much more than SVN actually) and I use it for all my
projects,
but I doubt moving to Git would solve anything.
IMO even CVS was quite enough for our development model.
On 11/25/2010 04:47 AM, Pierre Joye wrote:
hi,
We have moved not too long ago and for what I see it gave
the branching/merging is much better, so if not anything, but could
solve/make thing easier, especially if we decide to work with more branches
(either for cherry picking, or multiple stable branches, for example the
suggested lts method)
On Thu, Nov 25, 2010 at 10:39 AM, Antony Dovgal
GIT is realy nice!
git merging magic!
On 25/11/10 07:41, Lester Caine wrote:
Patrick ALLAERT wrote:
2010/11/25 Lester Caineles...@lsces.co.uk:
Have you used git on Windows Pierre ... It is a joke!
Yes one can get it to work, but only if you do not use anything that
the git
cygwin install destroys! And as yet there is no consensus
Nick Pope wrote:
Ultimately I'm a +1 for Git. The proper branching/merging would solve
so many issues that have been addressed recently on the mailing list
regarding the pollution of trunk with incomplete and broken features, as
well as BC breakage by feature removal...
I have been using
On 25.11.2010 10:20, David Soria Parra wrote:
- A few old timers didn't want us using Git
They'll get over it.
The great thing is... that git can work as an svn client or You can work
with svn client on a github git repo ( afair ? ) ;-)
- Krzysztof
--
PHP Internals - PHP Runtime
On 2010-11-23, Felipe Pena felipe...@gmail.com 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
On 2010-11-23, Felipe Pena felipe...@gmail.com wrote:
--001636eef06580573f0495ae312f
Content-Type: text/plain; charset=UTF-8
Hi,
With the recent chaos in the way we begin and ended releases, we would
like to propose a clean way to deal with releases and related decisions: [1]
PHP releases
On 25/11/10 10:14, Lester Caine wrote:
Nick Pope wrote:
Ultimately I'm a +1 for Git. The proper branching/merging would solve
so many issues that have been addressed recently on the mailing list
regarding the pollution of trunk with incomplete and broken features, as
well as BC breakage by
2010/11/25 Jani Taskinen jani.taski...@iki.fi:
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,
On Thu, Nov 25, 2010 at 12:47 PM, Lester Caine les...@lsces.co.uk wrote:
( And installing msysgit broke ssh access to my customer sites from the
windows box. A couple of days working on fixing that produced no solution,
while simply un-installing it restored all of the broken functionality. It
On 25/11/10 11:47, Lester Caine wrote:
Nick Pope wrote:
I really couldn't make sense of this. Also - did you actually read my
last reply? The link I sent you linked to this:
http://www.eclipse.org/egit/
I've never used it. I can't vouch for it. But if that isn't some form of
integration, I
On 25/11/10 12:22, Pierre Joye wrote:
On Thu, Nov 25, 2010 at 12:47 PM, Lester Caineles...@lsces.co.uk wrote:
( And installing msysgit broke ssh access to my customer sites from the
windows box. A couple of days working on fixing that produced no solution,
while simply un-installing it
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
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,
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 sort
On Thu, 25 Nov 2010, Pierre Joye wrote:
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use git in one way or
On 24 November 2010 18:03, Nathan Nobbe quickshif...@gmail.com wrote:
Ummm... never mind!
Sorry for the noise!
-nathan
On Wed, Nov 24, 2010 at 11:00 AM, Nathan Nobbe quickshif...@gmail.comwrote:
Hi all,
I had a thought this morning and would like some feedback. Don't you think
it
Derick Rethans wrote:
On Thu, 25 Nov 2010, Pierre Joye wrote:
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
developers here are on github or use
On 25 November 2010 07:16, Patrick ALLAERT patrickalla...@php.net wrote:
TortoiseGit
So, I now have TortoiseCVS, TortoiseSVN _and_ TortoiseGit. Gee! My
windows is slow enough ... now I'm pulling along 3 tortoises.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html :
On Thu, Nov 25, 2010 at 3:26 PM, Lester Caine les...@lsces.co.uk wrote:
Derick Rethans wrote:
On Thu, 25 Nov 2010, Pierre Joye wrote:
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in
On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans der...@php.net 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.
On Mon, 22 Nov 2010, Felipe Pena wrote:
[1] http://wiki.php.net/rfc/releaseprocess
Now I've thought a bit more about it, I'm trying to reply to this with
some constructive comments. I'm reordering it a bit in the response
where it makes sense to do. In a general way, some of the things in here
On Thu, 25 Nov 2010, Gustavo Lopes wrote:
On Thu, 25 Nov 2010 14:05:43 -, Derick Rethans der...@php.net 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
On Thu, 25 Nov 2010, Ferenc Kovacs wrote:
On Thu, Nov 25, 2010 at 3:26 PM, Lester Caine les...@lsces.co.uk wrote:
Derick Rethans wrote:
On Thu, 25 Nov 2010, Pierre Joye wrote:
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
On Wed, 24 Nov 2010, Philip Olson wrote:
Please not I'm not requesting to do it now and here, only trying to
get a feeling/poll about git usage.
The main reasons we moved to SVN and not Git include:
- Less of a learning curve, because SVN is like CVS
- Most of the CVS-SVN work was
I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled gardens. It might be easy enough to
share, but discovery is a lot harder.
Hello out there!
This morning I asked myself whether it's possible to extend a class without
calling the child, but the initially extended class?
It can, in some circumstances, really be important.
I.e.: I build an CLI-shell interface for some back-end stuff I'd to do - and
it really is a pain in
On Thu, 2010-11-25 at 16:44 +0100, Kenan Sulayman wrote:
So - is there a way to dynamically extend a class (not the
traditionally
get-the-class,-clone-the-class-and-add-sugar-way) ?
After reading this three times i interpret it like I want to add stuff
to the instance and no that is not
On Thu, Nov 25, 2010 at 16:28, Herman Radtke hermanrad...@gmail.com wrote:
I am not in favour; I will repeat what I just wrote to Davey:
DVCS is also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible instead of walled
Okay. :/
After all, thank you for the interjection of Runkit ^^
I think, I'll give it a try.. :)
Thanks - and uhh - my signature really looks ugly in the mailing-list.
Thanks for letting me know ;)
Cheers,
--
(c) *Kenan Sulayman*
*Freelance Designer and Programmer*
*Life's Live Poetry*
On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans der...@php.net 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
On 2010-11-25, Derick Rethans der...@php.net wrote:
On Thu, 25 Nov 2010, Pierre Joye wrote:
We have moved not too long ago and for what I see it gave some
opportunities to many of us to see what are the other tools on the
market, git and github in particular. I think 99% of the active
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, subversion
On 2010-11-25, Andi Gutmans a...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, November 24, 2010 5:47 PM
To: PHP internals
Subject: [PHP-DEV] git anyone?
We have moved not too long ago and for what I see it gave some
-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 the version
there.
Major BC
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 changes
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, Nov 25, 2010 at 6:11 PM, Andi Gutmans a...@zend.com 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 off 5.4
Who says it has to be 5.4?
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 foremost by
On Thu, Nov 25, 2010 at 5:54 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
It might be easy enough to share, but discovery is a lot harder.
Perhaps. But that's what mailing lists, issue trackers, and blogs are
for. I've had very little issue with discovery, to be honest.
And
Developers can already wall themselves off now with the github mirror.
No. People. Stop saying that. It simply isn't true.
The 'github mirror' hasn't been active for 6months.
It got killed because our box simply couldn't handle the job.
My mistake. The github mirror really isn't the point
hi Rasmus,
2010/11/25 Rasmus Lerdorf ras...@lerdorf.com:
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
On 2010-11-25, Herman Radtke hermanrad...@gmail.com wrote:
Developers can already wall themselves off now with the github mirror.
No. People. Stop saying that. It simply isn't true.
The 'github mirror' hasn't been active for 6months.
It got killed because our box simply couldn't handle the
-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 17:11 +, Andi Gutmans wrote:
-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 trunk I think we are in pretty
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 PHP 6
Hi,
Completely different topic :)
I've been looking a bit into performance around json encoding,
hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled
and often transmitted over the wire.
I know there have been some high-end apps that have benefited from some custom
2010/11/25 Andi Gutmans a...@zend.com:
-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
As much as i might not have enough Karma to vote, being only involved
in tests, but i think git would be a great fit.
I agree with Phillip that we need to address the issues mentioned
before if we want to move over, but our community includes guys like
Travis Swicegood, who quite literally wrote
I think there is much to gain by improving the serialization speed in
PHP. It is used everywhere from caches like memcache, to sessions or
manual data input into DB. I would say that there are very few
non-trivial apps that would not benefit from a more compact and faster
serializer.
In our
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
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 out
-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
We also need that non-null
On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans a...@zend.com wrote:
-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
On 11/25/10 10:33 AM, Andi Gutmans wrote:
-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:
On 11/25/10 10:43 AM, Pierre Joye wrote:
On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans a...@zend.com wrote:
-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
-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 I agree. We may be able to skip this
On Thu, Nov 25, 2010 at 7:52 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/25/10 10:43 AM, Pierre Joye wrote:
On Thu, Nov 25, 2010 at 7:33 PM, Andi Gutmans a...@zend.com wrote:
-Original Message-
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Sent: Thursday, November 25, 2010
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 extension
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
Hi,
I think it would, a lot of sites/apps nowadays rely a lot on JSON
encoding/decoding, plus a lot of technologies are relying on serialization/json
encoding (Memcached, Redis, to name a few) at the PHP level, which can be a
really big performance eater if you use it a lot.
On the other hand,
hi,
For the record here, igbinary is a very good example of such optimization:
http://opensource.dynamoid.com/
On Thu, Nov 25, 2010 at 6:47 PM, Andi Gutmans a...@zend.com wrote:
Hi,
Completely different topic :)
I've been looking a bit into performance around json encoding,
On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com wrote:
For the record here, igbinary is a very good example of such optimization:
http://opensource.dynamoid.com/
igbinary is a nice extension indeed. However, for those of us who have
environments which include multiple
On Thu, Nov 25, 2010 at 8:47 PM, Jonah H. Harris jonah.har...@gmail.com wrote:
On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com wrote:
For the record here, igbinary is a very good example of such optimization:
http://opensource.dynamoid.com/
igbinary is a nice extension
Hi everyone,
I've been taking another look at iterators lately, and compiled trunk and
started experimenting with traits. I also looked at an old mail from Marcus
regarding iterator_apply, and find myself wondering why there isn't just an
'apply' method as part of the Iterator hierarchy itself.
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/5 going forward. Sure, I have a track
On Thu, Nov 25, 2010 at 16:56, Zeev Suraski z...@zend.com 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
Is it just unusually cold weather for this time of year or did the hell
just freeze over? :-o
Couldn't agree more on both points and I had the same thoughts about
getting stuck with 5.x releases forever. And not getting any release out
soon from trunk if this thread drags on too long.
Maybe
On Thu, Nov 25, 2010 at 10:56 PM, Zeev Suraski z...@zend.com 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
Just read over the BSON spec, looks fairly interesting, the only bit
that appears to be missing for PHP purposes is object support. We
would need to introduce custom type on top of standard BSON. However
from compactness and consistency standpoint it looks fairly appealing.
On Thu, Nov 25, 2010
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
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
Hi
2010/11/25 Zeev Suraski z...@zend.com:
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
78 matches
Mail list logo
