On Apr 3, 2015 11:55 AM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
+1 This is exactly it. The longer older versions are supported the
longer they remain in the wild.
5.3 is unsupported and still has over 40%. 5.2 is dead for 4 years by
now and still beats 5.5 by factor of more
On 3 April 2015 05:55:27 GMT+01:00, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
+1 This is exactly it. The longer older versions are supported the
longer they remain in the wild.
5.3 is unsupported and still has over 40%. 5.2 is dead for 4 years by
now and still beats 5.5 by factor of
Hi!
It seems to me we are mixing two questions : can 'small
self-contained' changes be introduced in a patch release, and how
'small' and 'self-contained' a change must be not to require an RFC ?
It seems implicit that, once an RFC is written, it is not a 'small
self-contained' change
Hi!
+1 This is exactly it. The longer older versions are supported the
longer they remain in the wild.
5.3 is unsupported and still has over 40%. 5.2 is dead for 4 years by
now and still beats 5.5 by factor of more than 2. So I don't think just
unsupporting something will make a big
De : Stanislav Malyshev [mailto:smalys...@gmail.com]
The questions here are:
* will this code break any code running with PHP before that patch?
* does this code change the language in any way?
OK, so I think there's a misunderstanding here. What you describing is
exactly my position -
On Thu, Apr 2, 2015 at 12:27 PM, Dan Ackroyd dan...@basereality.com wrote:
Ferenc Kovacs wrote:
this would also eliminate
the confusion, that something is present in 5.6.27 but not in
5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will
land in 5.5.41).
I think the
Ferenc Kovacs wrote:
this would also eliminate
the confusion, that something is present in 5.6.27 but not in
5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will
land in 5.5.41).
I think the solution to this is pretty clear, as Rowan put it:
Rowan Collins wrote:
- Once a
Hi!
That one is rather easy to follow and disallow any kind of bully pushes.
Easy to follow != good to follow. I have no idea what you mean by
bully pushes.
Which years are you referring to?
The ones that will pass between feature being contributed (which if
enhancements are banned in
On 01/04/15 07:28, Stanislav Malyshev wrote:
You may think if we ban
enhancement then people would jump to 7.x in droves - but I have yet to
see anybody taking decisions this way. So far statistics says people
still are in 5.3 and 5.4 massively - though we do not add features there
for quite
On Wed, Apr 1, 2015 at 1:28 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
That one is rather easy to follow and disallow any kind of bully pushes.
Easy to follow != good to follow. I have no idea what you mean by
bully pushes.
Which years are you referring to?
The ones that will
Hello,
Am 30.03.2015 um 12:04 schrieb Ferenc Kovacs:
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
On Wed, Apr 1, 2015 at 1:23 PM, François Laupretre franc...@php.net wrote:
De : Dennis Birkholz [mailto:den...@birkholz.biz]
in my opinion all feature changes should go in the next X.Y version and
should require an RFC.
The reason is that small self-contained changes that get pulled in
De : Dennis Birkholz [mailto:den...@birkholz.biz]
in my opinion all feature changes should go in the next X.Y version and
should require an RFC.
The reason is that small self-contained changes that get pulled in
without a discussion on internals and an RFC can easily lead to bad
design
De : Ferenc Kovacs [mailto:tyr...@gmail.com]
I could accept any decision between holding off new features until next
minor/major and allowing features explicitly without going through an RFC,
but I
want to have an explicit definition on what is allowed and how should the
case-
by-case
On Wed, Apr 1, 2015 at 6:28 PM, François Laupretre franc...@php.net wrote:
De : Ferenc Kovacs [mailto:tyr...@gmail.com]
I could accept any decision between holding off new features until next
minor/major and allowing features explicitly without going through an
RFC, but I
want to have
On Tue, Mar 31, 2015 at 9:44 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev
smalys...@gmail.com wrote:
This is a straw man as far as the points I made are concerned. I'm
talking about the risk of switching from 5.5 to 5.6, which is
Hi,
On Wed, Apr 1, 2015 at 6:15 PM, Michael Wallner m...@php.net wrote:
On 01 04 2015, at 18:28, François Laupretre franc...@php.net wrote:
De : Ferenc Kovacs [mailto:tyr...@gmail.com]
I could accept any decision between holding off new features until next
minor/major and allowing
Hi!
I am sorry for the contributor but my example is
https://github.com/php/php-src/pull/1145
(DateTime::createFromImmutable() method) which was posted here on the
list, got three negative replies but was merged nevertheless. I will not
reproduce the arguments here but now the door for a
Hi Stas,
Am 01.04.2015 um 21:19 schrieb Stanislav Malyshev:
Hi!
I am sorry for the contributor but my example is
https://github.com/php/php-src/pull/1145
(DateTime::createFromImmutable() method) which was posted here on the
list, got three negative replies but was merged nevertheless. I
Hi!
As I mentioned this wasn't something without precedence, but seeing how
Derick(ext/date lead author/maintainer) was explicitly against this
change, and there were no favorable response from the list I tend to
agree with the revert.
Derick reviewed that patch and I didn't see him even
Hi!
And Derick wrote: (in http://markmail.org/message/ukwizupev32ld5tg)
I am against this addition, even though the patch looks OK. That is
not any objection from him except for small CS fixes but I don't know
what discussion happened off-list.
OK, I missed that one. I'll revert it then.
--
Hi!
That is right and I think that is the reality we have to face: most
users use distro versions. They get a new version when they need to
upgrade their distro every few years.
I'm not sure where you got this statistics from, but as I said, it is
very easy to make .rpm or .deb with source
Hi!
The questions here are:
* will this code break any code running with PHP before that patch?
* does this code change the language in any way?
OK, so I think there's a misunderstanding here. What you describing is
exactly my position - enhancements that are a) small and b)
self-contained
On 01 04 2015, at 18:28, François Laupretre franc...@php.net wrote:
De : Ferenc Kovacs [mailto:tyr...@gmail.com]
I could accept any decision between holding off new features until next
minor/major and allowing features explicitly without going through an RFC,
but I
want to have an
Hi!
Debian, Ubuntu and CentOS: ~21,23%
(I assume here like Anthony that the installs matching a distribution
specific version always come from that distribution).
Pretty big one, I'd say, but even with this one you only get 1/5. Also,
as I said, it's very easy to take distro package and
Hi,
Am 01.04.2015 um 22:36 schrieb Stanislav Malyshev:
Debian, Ubuntu and CentOS: ~21,23%
(I assume here like Anthony that the installs matching a distribution
specific version always come from that distribution).
Pretty big one, I'd say, but even with this one you only get 1/5. Also,
as
On Wed, Apr 1, 2015 at 9:38 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
As I mentioned this wasn't something without precedence, but seeing how
Derick(ext/date lead author/maintainer) was explicitly against this
change, and there were no favorable response from the list I tend
Damn Gmail... I just top-posted. I'm going to go away for a while now...
On Wed, Apr 1, 2015 at 4:19 PM Trevor Suarez ric...@gmail.com wrote:
Author of PR https://github.com/php/php-src/pull/1145 here.
I'm really quite sorry. I didn't mean to create a mess here. I was just
trying to
Hi,
Am 01.04.2015 um 21:43 schrieb Stanislav Malyshev:
That is right and I think that is the reality we have to face: most
users use distro versions. They get a new version when they need to
upgrade their distro every few years.
I'm not sure where you got this statistics from, but as I
Author of PR https://github.com/php/php-src/pull/1145 here.
I'm really quite sorry. I didn't mean to create a mess here. I was just
trying to contribute. :/
Unfortunately, whether or not an RFC was necessary for an addition like
this wasn't very clear. I'm an internals noob, so I simply tried to
Hi Trevor,
Am 01.04.2015 um 22:19 schrieb Trevor Suarez:
Author of PR https://github.com/php/php-src/pull/1145 here.
I'm really quite sorry. I didn't mean to create a mess here. I was just
trying to contribute. :/
I am sorry I caused this mess by using your PR (or better: the
acceptance of
Stanislav Malyshev wrote on 30/03/2015 23:10:
Hi!
If an organisation has standardised on an old version of PHP, there's a
By old you're meaning current stable, I presume.
No, current stable is 5.6.x; people have been talking about backporting
to 5.5.x (which has 2 months of active support
Am 31.03.2015 22:45 schrieb Rowan Collins rowan.coll...@gmail.com:
- Up until the first release candidate of x.y.0, small features can be
added to both the most recent live branch and the new branch being prepared
for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and
7.1-pre).
-
Hi!
- Up until the first release candidate of x.y.0, small features can be
added to both the most recent live branch and the new branch being
prepared for release (so, right now, 5.6.x and 7.0-pre; next summer,
7.0.x and 7.1-pre).
- Once a new x.y.0 release is ready, x.y-1.z releases should
Hi!
The problem is always a definition question, a very subjective question.
Fortunately, we can discuss it, we're not limited to blindly following
predefined set of rules.
I do not really buy the I am stuck with x.y as one has the same
problem already. And he has barely a 2 years window to
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev smalys...@gmail.com
wrote:
This is a straw man as far as the points I made are concerned. I'm
talking about the risk of switching from 5.5 to 5.6, which is pretty
low.
Switching to 5.6 would be useless since what is being propose it to
Sorry for the double reply, but I wanted to pick up on one particular point.
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
That's not quite how it works; the distro package maintainers
maintain a
sort of forked version of upstream code, combining a
hi,
ps: please keep the xyz wrote, makes harder to read your replies without it
On Wed, Apr 1, 2015 at 2:57 AM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
The problem is always a definition question, a very subjective question.
Fortunately, we can discuss it, we're not limited to
Hi!
That's not quite how it works; the distro package maintainers maintain a
sort of forked version of upstream code, combining a well-tested
upstream release with a set of patches, many of which will be backported
fixes from newer releases. So the current package in Ubuntu 14.04 LTS
[see
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
https://github.com/php/php-src/pull/1204
On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner m...@php.net wrote:
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to
On Mar 30, 2015 6:15 PM, Michael Wallner m...@php.net wrote:
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific
On Mon, Mar 30, 2015 at 3:10 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Mar 30, 2015 at 1:15 PM, Michael Wallner m...@php.net wrote:
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments
On 30/03/15 12:04, Ferenc Kovacs wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
On 30/03/2015 19:50, Stanislav Malyshev wrote:
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working
on a project, and you
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer working
on a project, and you noticed there's some small functionality missing
that
Hi!
If an organisation has standardised on an old version of PHP, there's a
By old you're meaning current stable, I presume.
fair chance that the builds they are using are not from php.net, but
from their OS distribution. As has been mentioned here before, these
There are no builds on
On Mon, Mar 30, 2015 at 8:50 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
I tend to agree that it would be easier for all parties if we stop
adding stuff in micro versions, as it is easier to remember and
I don't think it is a good idea. Imagine you are a PHP developer
On Mon, Mar 30, 2015 at 4:04 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
I know that our official release process allows that, but there are some
reasonable arguments against doing that and this topic was brought up
multiple times related to specific fixes.
I have two open PRs like that:
49 matches
Mail list logo
