On Fri, Aug 29, 2014 at 3:03 AM, Johannes Schlüter
wrote:
> On Fri, 2014-08-29 at 00:12 +0100, Andrea Faulds wrote:
>> I don’t see the need, though. For cases where we added stuff after release,
>> just make an extra tag.
>
> $ git tag | wc -l
> 937
> $ git branch -r | grep origin | wc -l
> 128
>
Hi Alain,
On 29 Aug, 2014, at 8:43 am, Alain Williams wrote:
> I notice that in the precedence chart the new **= operator is missing:
>
> http://uk1.php.net/manual/en/language.operators.precedence.php
>
> The announcement (below) says that it is right associative, but the precedent
> chart abo
On 29 Aug 2014, at 01:43, Alain Williams wrote:
> I notice that in the precedence chart the new **= operator is missing:
>
> http://uk1.php.net/manual/en/language.operators.precedence.php
It’s not on docs.php.net either, so the manual must just be out-of-date.
> The announcement (below) says
I notice that in the precedence chart the new **= operator is missing:
http://uk1.php.net/manual/en/language.operators.precedence.php
The announcement (below) says that it is right associative, but the precedent
chart above says that it is left associative. From the example it seems to be
right a
On Fri, 2014-08-29 at 00:12 +0100, Andrea Faulds wrote:
> I don’t see the need, though. For cases where we added stuff after release,
> just make an extra tag.
$ git tag | wc -l
937
$ git branch -r | grep origin | wc -l
128
Not sure creating more tags makes things really "cleaner", I made a
prop
On 28 Aug 2014, at 23:44, Johannes Schlüter wrote:
> On Fri, 2014-08-29 at 01:34 +0300, Andrey Andreev wrote:
>
>> Tags preserve history well enough, as previously noted - they are
>> basically immutable branches. This looks like a no-brainer to me.
>
> This is not exactly true - we have cases
On Fri, 2014-08-29 at 01:34 +0300, Andrey Andreev wrote:
> Tags preserve history well enough, as previously noted - they are
> basically immutable branches. This looks like a no-brainer to me.
This is not exactly true - we have cases where where, for whatever
reason, commits were made after the t
Hi,
On Fri, Aug 29, 2014 at 1:14 AM, Johannes Schlüter
wrote:
> On Thu, 2014-08-28 at 20:55 +0200, Julien Pauli wrote:
>> Looking at git branches, 5.0, 5.1 and 5.2 still have their respective
>> main branches (which is all right and good).
>>
>> However, they dont have their release branch refere
On Thu, 2014-08-28 at 20:55 +0200, Julien Pauli wrote:
> Looking at git branches, 5.0, 5.1 and 5.2 still have their respective
> main branches (which is all right and good).
>
> However, they dont have their release branch references (5.1.1 , 5.1.2
> etc...) , however they still show their own rel
Hi!
> If https://bugs.php.net/bug.php?id=67644 could be fixed in 5.4.33 (and
> 5.5 as well) it would be really great !
Thank you, I will take a look.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
Hi,
If https://bugs.php.net/bug.php?id=67644 could be fixed in 5.4.33 (and
5.5 as well) it would be really great !
Thanks,
Jocelyn
Le 28/08/2014 23:13, Stas Malyshev a écrit :
Hi!
5.6.0 has been released, and first thing I'd like to congratulate all
who participated in it with this great
Hi!
5.6.0 has been released, and first thing I'd like to congratulate all
who participated in it with this great milestone.
Second thing, that means 5.4.33 would be the last release including
non-security fixes. With RC1 planned next Tuesday, this means if you've
got any non-security issues that
Hi Derick,
On Thu, August 28, 2014 17:23, Derick Rethans wrote:
> On Fri, 22 Aug 2014, Derick Rethans wrote:
>
>
>> On Fri, 22 Aug 2014, Anatol Belski wrote:
>>
>>
>>> as there are many data type changes, here's an idea on how to simplify
>>> the merges. Git supports custom merge drivers which att
On 28 August 2014 19:55, Julien Pauli wrote:
> Hello,
>
> We all know 5.3 is now EOL.
>
> Looking at git branches, 5.0, 5.1 and 5.2 still have their respective
> main branches (which is all right and good).
>
> However, they dont have their release branch references (5.1.1 , 5.1.2
> etc...) , howe
On Thu, Aug 28, 2014 at 8:55 PM, Julien Pauli wrote:
> Hello,
>
> We all know 5.3 is now EOL.
>
> Looking at git branches, 5.0, 5.1 and 5.2 still have their respective
> main branches (which is all right and good).
>
> However, they dont have their release branch references (5.1.1 , 5.1.2
> etc..
On Aug 22, 2014 1:39 PM, "Derick Rethans" wrote:
>
> On Fri, 22 Aug 2014, Anatol Belski wrote:
>
> > as there are many data type changes, here's an idea on how to simplify
> > the merges. Git supports custom merge drivers which attracted my
> > attention, so I've ended up with the following trick:
On 28 Aug 2014, at 19:55, Julien Pauli wrote:
> But, thoughts to clean *release branches* from our git for *EOL PHP
> versions*, like 5.3 ?
> Tag references should be enough for history, IMHO
It’s my understanding that a tag is merely an immutable branch (or a branch is
merely a mutable tag),
Hello,
We all know 5.3 is now EOL.
Looking at git branches, 5.0, 5.1 and 5.2 still have their respective
main branches (which is all right and good).
However, they dont have their release branch references (5.1.1 , 5.1.2
etc...) , however they still show their own release tags, which is
also all
On Thu, 2014-08-28 at 10:07 +0200, Sebastian Bergmann wrote:
> Am 28.08.2014 um 10:04 schrieb Pierre Joye:
> > ext/hash can have it anyway. I did not look at it if it makes sense to
> > use it in other parts.
>
> Sorry for not bein more clear: yes, I was thinking about adding it to
> ext/hash, o
On 22 Aug 2014, at 12:36, Derick Rethans wrote:
> Although I think it is good to make it work the same on every platform,
> I do think that changing it to *match* what the most used compiler (GCC)
> on our most used platform (Linux/AMD64) is what the new behaviour should
> be like — not somet
Just implement and show it working, then i'd say the guys will react.
28 авг. 2014 г. 18:24 пользователь "Derick Rethans"
написал:
> On Fri, 22 Aug 2014, Derick Rethans wrote:
>
> > On Fri, 22 Aug 2014, Anatol Belski wrote:
> >
> > > as there are many data type changes, here's an idea on how to
>
On Fri, 22 Aug 2014, Derick Rethans wrote:
> On Fri, 22 Aug 2014, Anatol Belski wrote:
>
> > as there are many data type changes, here's an idea on how to
> > simplify the merges. Git supports custom merge drivers which
> > attracted my attention, so I've ended up with the following trick:
>
>
Hello!
The PHP Development Team would like to announce the immediate release of
PHP 5.6.0. This release includes a large number of new features and bug
fixes.
A separate release announcement is also available. For changes in PHP
5.6.0 since PHP 5.5, please consult the PHP 5 ChangeLog.
Release An
Am 28.08.2014 um 10:04 schrieb Pierre Joye:
> ext/hash can have it anyway. I did not look at it if it makes sense to
> use it in other parts.
Sorry for not bein more clear: yes, I was thinking about adding it to
ext/hash, of course. It might make sense, though, to evaluate whether
it can also b
On Thu, Aug 28, 2014 at 10:00 AM, Sebastian Bergmann wrote:
> I recently came across SipHash [1] (which is "a family of pseudorandom
> functions (a.k.a. keyed hash functions) optimized for speed on short
> messages") and am wondering whether it would make sense to add support
> for it to PHP.
I recently came across SipHash [1] (which is "a family of pseudorandom
functions (a.k.a. keyed hash functions) optimized for speed on short
messages") and am wondering whether it would make sense to add support
for it to PHP.
Thoughts?
--
[1] https://131002.net/siphash/
--
PHP Internals
26 matches
Mail list logo
