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
https://github.com/php/php-src/pull/969
and of course there are a bunch of similar ones from other people, and
there are cases when somebody simply pushes a change like that, other times
somebody points out that it should require an RFC(
https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
most of the times we simply don't know what to do, and eventually we just
let the PR/patch to rot and die.
I would like to know if we can come up with a rule which can have consensus
behind it, and maybe formalize it as an extension to our current
releaseprocess rfc.
What do you think?
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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
https://github.com/php/php-src/pull/969
and of course there are a bunch of similar ones from other people, and
there are cases when somebody simply pushes a change like that, other times
somebody points out that it should require an RFC(
https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
most of the times we simply don't know what to do, and eventually we just
let the PR/patch to rot and die.
I would like to know if we can come up with a rule which can have consensus
behind it, and maybe formalize it as an extension to our current
releaseprocess rfc.What do you think?
How about:
It's okay, if it does not need version_compare(PHP_VERSION) but can be
tested by e.g. defined("SOME_CONSTANT") or function_exists("fn")?
--
Regards,
Mike
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
https://github.com/php/php-src/pull/969
and of course there are a bunch of similar ones from other people, and
there are cases when somebody simply pushes a change like that, other
times
somebody points out that it should require an RFC(
https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
most of the times we simply don't know what to do, and eventually we
just
let the PR/patch to rot and die.
I would like to know if we can come up with a rule which can have
consensus
behind it, and maybe formalize it as an extension to our current
releaseprocess rfc.What do you think?
How about:
It's okay, if it does not need
version_compare(PHP_VERSION)but can be
tested by e.g.defined("SOME_CONSTANT")orfunction_exists("fn")?
We have php version constants, major, minor and patch.
To me it all looks the same, ugly #ifdef like. Now that we release a x.y+1
every year, I do not see the point to continue to force our users to
clutter their codes with such tests.
--
Regards,
Mike
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
https://github.com/php/php-src/pull/969
and of course there are a bunch of similar ones from other people, and
there are cases when somebody simply pushes a change like that, other
times
somebody points out that it should require an RFC(
https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
most of the times we simply don't know what to do, and eventually we just
let the PR/patch to rot and die.
I would like to know if we can come up with a rule which can have
consensus
behind it, and maybe formalize it as an extension to our current
releaseprocess rfc.What do you think?
How about:
It's okay, if it does not need
version_compare(PHP_VERSION)but can be
tested by e.g.defined("SOME_CONSTANT")orfunction_exists("fn")?--
Regards,
Mike
hi,
That is a good think to keep in mind, but I don't think that is the only
thing matters.
Adding a new function/constants -> there is a chance that we break
somebodys code in a micro version
Adding a new class method -> can be problematic if somebody extended the
class and used the same method but with different signature.
As of now, we don't really consider this kind of things as BC breaks
(otherwise nothing but new optional arguments would be allowed in micro and
minor versions), but it is a PITA for those whose app we break in a micro
version.
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 communicate that
something was added in x.y (as in x.y.0) than the current situation where
some stuff is just only present in 5.6.27, plus 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).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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
https://github.com/php/php-src/pull/969
and of course there are a bunch of similar ones from other people, and
there are cases when somebody simply pushes a change like that, other
times
somebody points out that it should require an RFC(
https://wiki.php.net/rfc/json_preserve_fractional_part for example),
but
most of the times we simply don't know what to do, and eventually we
just
let the PR/patch to rot and die.
I would like to know if we can come up with a rule which can have
consensus
behind it, and maybe formalize it as an extension to our current
releaseprocess rfc.What do you think?
How about:
It's okay, if it does not need
version_compare(PHP_VERSION)but can be
tested by e.g.defined("SOME_CONSTANT")orfunction_exists("fn")?--
Regards,
Mikehi,
That is a good think to keep in mind, but I don't think that is the only
thing matters.
Adding a new function/constants -> there is a chance that we break
somebodys code in a micro version
Adding a new class method -> can be problematic if somebody extended the
class and used the same method but with different signature.
As of now, we don't really consider this kind of things as BC breaks
(otherwise nothing but new optional arguments would be allowed in micro and
minor versions), but it is a PITA for those whose app we break in a micro
version.
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 communicate that
something was added in x.y (as in x.y.0) than the current situation where
some stuff is just only present in 5.6.27, plus 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 agree.
That was the case for 5.6 for example, that got added new functions etc...
up to 5.6.3 AFAIR.
As everything can be considered as beeing a BC break for at least someone
on Earth, I admit it is hard to understand the meaning of "small
self-contained additions in a micro version" :-p
Julien.Pauli
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 would improve things a lot for you - like parameter to some
function or returning some value that is missing. You could easily
contribute it, but if it can't go in minor version there's no point for
you to even bother. Because even if your org is super-up-to-date, they
run 5.6, most realistically - 5.5, and if it's like the majority - it'd
be 5.4 and worse. You could hope to convince your bosses and your ops to
go to 5.6 and keep it reasonably updated within 5.6, but if the only
addition you can make is 7.1, it's the lost cause - by the time your org
could go to 7.1 your project will be long done (or at least long
designed to work without this new feature) and you may be already
working in another company. Yes, we have releases (almost) each year,
but adoption of them is much slower, and with all BC breaks in 7.0 it
would probably be even slower when going from 5 to 7, so this means
doing small improvements to PHP is essentially of no practical value for
PHP developer since there's no chance this improvement can be used in
the lifetime of a typical project.
I do not think it would be good for PHP.
As everything can be considered as beeing a BC break for at least
someone on Earth, I admit it is hard to understand the meaning of "small
self-contained additions in a micro version" :-p
I do not think we should consider adding functions/options "BC break",
not by any sane definition of it. Of course, nothing prevents somebody
from using insane definitions, but it's of no concern to us.
Stas Malyshev
smalyshev@gmail.com
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 andI 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 would improve things a lot for you - like parameter to some
function or returning some value that is missing. You could easily
contribute it, but if it can't go in minor version there's no point for
you to even bother. Because even if your org is super-up-to-date, they
run 5.6, most realistically - 5.5, and if it's like the majority - it'd
be 5.4 and worse. You could hope to convince your bosses and your ops to
go to 5.6 and keep it reasonably updated within 5.6, but if the only
addition you can make is 7.1, it's the lost cause - by the time your org
could go to 7.1 your project will be long done (or at least long
designed to work without this new feature) and you may be already
working in another company.
If an organisation has standardised on an old version of PHP, there's a
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
generally track a particular patch release and cherry-pick fixes -
Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official
5.5.23, for instance. Anyone working in such an environment won't
receive the benefit of a new feature however far it is backported.
The obvious alternative avenues are to write a forward-compatible
userland version, or package an extension, both of which are likely to
reach a larger audience than a tail-end release like 5.5.23.
I can certainly see value in a special case for including things in both
5.6 and 7.x, both before and after 7.0 is released, but the the case for
backporting anything other than a genuine bug fix to 5.5.x right now
seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0
is released (by which point 5.6.x will presumably be in its
security-only phase).
As everything can be considered as beeing a BC break for at least
someone on Earth, I admit it is hard to understand the meaning of "small
self-contained additions in a micro version" :-p
I do not think we should consider adding functions/options "BC break",
not by any sane definition of it. Of course, nothing prevents somebody
from using insane definitions, but it's of no concern to us.
The problem is that there is no way to know, as a user, which function
names may become reserved in the future. There is an officially reserved
namespace "php", but it remains unused. So if functions can be added at
any time, the only way to guarantee your code won't break on a patch
upgrade is to treat the entire global namespace as additionally
reserved. I don't think it's at all "insane" to say that a patch version
shouldn't usurp non-reserved names.
Regards,
--
Rowan Collins
[IMSoP]
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 php.net, except for windows.php.net. Most
organizations I've encountered indeed use either distros or their own
distro-like packages (which usually mimick distro ones but have
modifications like additional packages, tweaking paths, adding/removing
configs or data, etc.).
generally track a particular patch release and cherry-pick fixes -
Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official
5.5.23, for instance. Anyone working in such an environment won't
receive the benefit of a new feature however far it is backported.
As per above, it's much easier to get 5.5.23 installed in the org than
7.1. I'm not overly familiar with particulates of Debian policies, but
if they have whole distro sitting on 5.5.9 when there's 5.5.23 out it's
bad, as their customers do not get bugfixes which may be essential for
them. I sincerely hope it's not the case. In any case, burden of
creating 5.5.23 package from debian 5.5.9 package is very low, most
competent ops would be able to do this, and the risk of following 5.5
line is not comparable to the risk of switching from 5.5 to 7.1.
The obvious alternative avenues are to write a forward-compatible
userland version, or package an extension, both of which are likely to
reach a larger audience than a tail-end release like 5.5.23.
I'm not sure how you mean to write an extension that would add an option
to json_encode for example.
I can certainly see value in a special case for including things in both
5.6 and 7.x, both before and after 7.0 is released, but the the case for
backporting anything other than a genuine bug fix to 5.5.x right now
seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0
is released (by which point 5.6.x will presumably be in its
security-only phase).
That means right now any enhancement somebody would propose would be
just released somewhere towards the end of next year. And since nobody
switches instantly, especially to the next major, their timeframe to use
it would be something like 4-5 years. I would have zero motivation as a
userland developer to work on a small change like adding an option that
I could benefit from in 5 years maybe. Would you?
The problem is that there is no way to know, as a user, which function
names may become reserved in the future. There is an officially reserved
That's true in general. But if you name your function something like
get_error_handler or mysql_connect_something, you must know you're on a
shaky ground. The argument "we can not add anything in the main
namespace because somebody could have named function exactly the same"
sounds hollow to me. Of course, for some cases it must be true, but most
people that don't use classes long learned to prefix or namespace their
functions, and
And, of course, this does not apply to adding options, etc.
reserved. I don't think it's at all "insane" to say that a patch version
shouldn't usurp non-reserved names.
I think in this form it is. There are no "reserved names" in functions,
and if you use mysql_* namespace functions and it clashes with functions
added by mysql extension, it's your fault. Same for other obvious cases.
--
Stas Malyshev
smalyshev@gmail.com
Stanislav Malyshev wrote:
I can certainly see value in a special case for including things in both
5.6 and 7.x, both before and after 7.0 is released, but the the case for
backporting anything other than a genuine bug fix to 5.5.x right now
seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0
is released (by which point 5.6.x will presumably be in its
security-only phase).That means right now any enhancement somebody would propose would be
just released somewhere towards the end of next year. And since nobody
switches instantly, especially to the next major, their timeframe to use
it would be something like 4-5 years. I would have zero motivation as a
userland developer to work on a small change like adding an option that
I could benefit from in 5 years maybe. Would you?
Have you considered developers targeting shared hosting? Working on an
improvement they have to wait for five years to use it is most certainly
annoying. However, introducing this feature in a revision might not
really help them at all.
--
Christoph M. Becker
Hi!
Have you considered developers targeting shared hosting? Working on an
improvement they have to wait for five years to use it is most certainly
annoying. However, introducing this feature in a revision might not
really help them at all.
Not immediately, but shared hoster much faster would upgrade from 5.5.9
to 5.5.23 than from 5.5.9 to 7.1. Also, if adding feature does not help
some specific group, it doesn't mean it shouldn't be done - because not
adding doesn't help all groups. So at least we can help people that do
have option to upgrade. What is being proposed that everybody has to
wait for years for even tiniest feature to become available. I don't
think it is a good idea. If that were the principle in PHP in its early
days, many people - probably including myself - would never start
contributing to core, since what's the point if they have to wait for
results of their labor to be useful to them for several years?
Stas Malyshev
smalyshev@gmail.com
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" remaining according to
http://php.net/supported-versions.php).
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 php.net, except for windows.php.net. Most
organizations I've encountered indeed use either distros or their own
distro-like packages (which usually mimick distro ones but have
modifications like additional packages, tweaking paths, adding/removing
configs or data, etc.).
Yes, "builds" is perhaps not the right word, but you got my meaning OK.
generally track a particular patch release and cherry-pick fixes -
Ubuntu 14.04 maintains a patched version of PHP 5.5.9 vs the official
5.5.23, for instance. Anyone working in such an environment won't
receive the benefit of a new feature however far it is backported.
As per above, it's much easier to get 5.5.23 installed in the org than
7.1. I'm not overly familiar with particulates of Debian policies, but
if they have whole distro sitting on 5.5.9 when there's 5.5.23 out it's
bad, as their customers do not get bugfixes which may be essential for
them. I sincerely hope it's not the case. In any case, burden of
creating 5.5.23 package from debian 5.5.9 package is very low, most
competent ops would be able to do this, and
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 http://packages.ubuntu.com/trusty/php5] is "5.5.9+dfsg-1ubuntu4.7",
and the Ubuntu Changelog shows 12 releases, mostly for security patches,
which is nearly as many as there have been upstream releases.
the risk of following 5.5
line is not comparable to the risk of switching from 5.5 to 7.1.
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.
The obvious alternative avenues are to write a forward-compatible
userland version, or package an extension, both of which are likely to
reach a larger audience than a tail-end release like 5.5.23.
I'm not sure how you mean to write an extension that would add an option
to json_encode for example.
Well, you could fork the JSON extension, I guess. But yes, not all
options are available in all cases.
I can certainly see value in a special case for including things in both
5.6 and 7.x, both before and after 7.0 is released, but the the case for
backporting anything other than a genuine bug fix to 5.5.x right now
seems fairly weak, as will the case for backporting to 7.0.x after 7.1.0
is released (by which point 5.6.x will presumably be in its
security-only phase).
That means right now any enhancement somebody would propose would be
just released somewhere towards the end of next year. And since nobody
switches instantly, especially to the next major, their timeframe to use
it would be something like 4-5 years. I would have zero motivation as a
userland developer to work on a small change like adding an option that
I could benefit from in 5 years maybe. Would you?
That's completely the opposite of what I said. I said I do think
adding small features to 5.6 may be justified, since 7.0 will be a more
painful upgrade.
The type of backporting I'm questioning is adding features to 5.5.x,
when we have 5.6.x released, and 7.0.x in preparation. And, after the
7.1.0 release towards the end of next year, I would not expect features
to be backported to 7.0.
The problem is that there is no way to know, as a user, which function
names may become reserved in the future. There is an officially reserved
That's true in general. But if you name your function something like
get_error_handler or mysql_connect_something, you must know you're on a
shaky ground. The argument "we can not add anything in the main
namespace because somebody could have named function exactly the same"
sounds hollow to me. Of course, for some cases it must be true, but most
people that don't use classes long learned to prefix or namespace their
functions, andAnd, of course, this does not apply to adding options, etc.
No, indeed. There, the cost is only on the developer having to ensure
that they don't deploy code relying on the new option to a server one
patch version too old.
reserved. I don't think it's at all "insane" to say that a patch version
shouldn't usurp non-reserved names.
I think in this form it is. There are no "reserved names" in functions,
and if you use mysql_* namespace functions and it clashes with functions
added by mysql extension, it's your fault. Same for other obvious cases.
That depends what you mean by "obvious". You could consider every
function name beginning str_* or array_* as "obviously" reserved for
future built-in functionality; but then you've got to reserve dozens of
prefixes like error_, file_, etc. So, for simplicity, you might as
well treat the global namespace as out of bounds.
I think a patch version should generally be installable without
thoroughly reading the Changelog, except in rare and widely publicised
situations where a security fix was found to be impossible without
breaking something. You shouldn't have to risk your code breaking
because you missed the line "new function get_error_handler()" somewhere
amongst the memory leak fixes and security patches.
Regards,
Rowan Collins
[IMSoP]
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 http://packages.ubuntu.com/trusty/php5] is "5.5.9+dfsg-1ubuntu4.7",
and the Ubuntu Changelog shows 12 releases, mostly for security patches,
which is nearly as many as there have been upstream releases.
I think this is all wrong, because I don't see how they can do better
testing with random set of patches than with real release version, but
that's beside the point. The point is it's very easy to make a
deployable package from php.net source pack, but it's much harder to
move an organization to different version that may cause BC breaks and
other disruption. It's both technical and organizational - try to
propose moving software from version 5.5.23 to 5.5.24 and from 5.x to
7.x and ask anybody which is riskier. Almost universally you'd be told
the latter is much riskier.
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 ban
any enhancements up to 7.1.
Well, you could fork the JSON extension, I guess. But yes, not all
options are available in all cases.
For most enhancements, no options but "wait for a couple of years" are
available unless you want to maintain a full-blown php fork.
That's completely the opposite of what I said. I said I do think
adding small features to 5.6 may be justified, since 7.0 will be a more
painful upgrade.
Then we agree. But the proposal here was to ban all enhancements in
released versions. This is just wrong, and I am glad you support it.
The type of backporting I'm questioning is adding features to 5.5.x,
when we have 5.6.x released, and 7.0.x in preparation. And, after the
7.1.0 release towards the end of next year, I would not expect features
to be backported to 7.0.
Depends on "features". In principle I'd be fine with enhancement going
only into 5.6, but given its abysmal adoption so far, practically I can
see the case for some stuff in 5.5 too. But I recognize it's chicken and
egg problem, so if we can reach consensus on 5.6, I can live with that.
No, indeed. There, the cost is only on the developer having to ensure
that they don't deploy code relying on the new option to a server one
patch version too old.
This is a regular "version requirement" concern which ops should be well
familiar with and be able to handle.
prefixes like error_, file_, etc. So, for simplicity, you might as
well treat the global namespace as out of bounds.
In my code, I'd be wary of putting non-prefixed functions into global
namespace. PHP versions is only one reason - if two libraries have
error_report() function, they never can be used together, not a good
thing. I'd rather call it my_library_error_report() if for some reason I
can't namespace it properly.
--
Stas Malyshev
smalyshev@gmail.com
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 ban
any enhancements up to 7.1.
Proposed by whom? The only mentions of 7.1 I've spotted have been from you, which is why I called it a straw man.
So, rather than arguing round in circles, here's what I would propose:
- 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 receive bug fixes only. Thus 5.5.x should not be receiving features.
- As an exception to the above, when releasing x.0.0, the previous branch may continue receiving small features, until it reaches the end of its "active support" phase. In other words, keep backporting things to 5.6.x after 7.0.0 is released, since adoption of the latter is likely to be slow. By the time 7.1.0 comes around, active support for 5.6 will have ended anyway, unless we make some other exception to the normal process.
This is very much a compromise between the SemVer ideal of a patch release, and the practical implications of a yearly release cycle. The aim is to make it obvious to users what they'll get in return for upgrading, and to smoothly transition a branch from "cutting edge" to "stable with bug fixes", then to "security only" and "end of life".
What do people think?
Regards,
Rowan Collins
[IMSoP]
Am 31.03.2015 22:45 schrieb "Rowan Collins" rowan.collins@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).- Once a new x.y.0 release is ready, x.y-1.z releases should receive bug
fixes only. Thus 5.5.x should not be receiving features.- As an exception to the above, when releasing x.0.0, the previous branch
may continue receiving small features, until it reaches the end of its
"active support" phase. In other words, keep backporting things to 5.6.x
after 7.0.0 is released, since adoption of the latter is likely to be slow.
By the time 7.1.0 comes around, active support for 5.6 will have ended
anyway, unless we make some other exception to the normal process.This is very much a compromise between the SemVer ideal of a patch
release, and the practical implications of a yearly release cycle. The aim
is to make it obvious to users what they'll get in return for upgrading,
and to smoothly transition a branch from "cutting edge" to "stable with bug
fixes", then to "security only" and "end of life".What do people think?
That sounds very reasonable, and would suit me fine :)
One issue that I think speaks for such an approach, is giving
new-small-features better exposure outside of developer circles. If
features only ever go into the-next-tree, they won't be seen and tried out
in the field until after that is committed as a new-stable release. The
feature also probably can't be added to the php.net documentation until
that release happens (right). Lots less eyes seeing it, finding problems
with it that might be rectified before next-becomes-stable.
I think there's a three layer hierarchy of adoption at play here, which
also can explain the low adoption figures of newest-stable. At the top, you
have next-stable, which will be visible almost exclusively to contributors,
and won't get any real world production exposure at all. Then you have the
current stable, which is used by shops (like mine...) that care about
building their own binaries, and that have a rather homogenous inhouse
codebase that can evolve to use new major and minor features in production.
And then there's the vast field which runs on distribution builds, which
seems to sit on the oldest supported stable version in existence until it's
faded out, and which doesn't care about new features at all.
Do I make sense? :)
best regards
Patrick
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 receive
bug fixes only. Thus 5.5.x should not be receiving features.- As an exception to the above, when releasing x.0.0, the previous
branch may continue receiving small features, until it reaches the end
of its "active support" phase. In other words, keep backporting things
to 5.6.x after 7.0.0 is released, since adoption of the latter is likely
to be slow. By the time 7.1.0 comes around, active support for 5.6 will
have ended anyway, unless we make some other exception to the normal
process.
This looks like a reasonable compromise.
--
Stas Malyshev
smalyshev@gmail.com
On Tue, Mar 31, 2015 at 9:44 PM, Rowan Collins rowan.collins@gmail.com
wrote:
On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev <
smalyshev@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 ban
any enhancements up to 7.1.Proposed by whom? The only mentions of 7.1 I've spotted have been from
you, which is why I called it a straw man.So, rather than arguing round in circles, here's what I would propose:
- 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 receive bug
fixes only. Thus 5.5.x should not be receiving features.- As an exception to the above, when releasing x.0.0, the previous branch
may continue receiving small features, until it reaches the end of its
"active support" phase. In other words, keep backporting things to 5.6.x
after 7.0.0 is released, since adoption of the latter is likely to be slow.
By the time 7.1.0 comes around, active support for 5.6 will have ended
anyway, unless we make some other exception to the normal process.This is very much a compromise between the SemVer ideal of a patch
release, and the practical implications of a yearly release cycle. The aim
is to make it obvious to users what they'll get in return for upgrading,
and to smoothly transition a branch from "cutting edge" to "stable with bug
fixes", then to "security only" and "end of life".What do people think?
+1
Sorry for the double reply, but I wanted to pick up on one particular point.
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 http://packages.ubuntu.com/trusty/php5] is
"5.5.9+dfsg-1ubuntu4.7",
and the Ubuntu Changelog shows 12 releases, mostly for security
patches,
which is nearly as many as there have been upstream releases.I think this is all wrong, because I don't see how they can do better
testing with random set of patches than with real release version, but
that's beside the point.
It may actually be the loose upstream definition of stability that motivates packagers to do this - they don't want to include new features, with their own potential bugs. It seems to be common practice, at least in the Debian ecosystem, so evidently they think it works out for the best.
Note that they also continue to maintain their patches after the corresponding release branch is EOL on php.net. For instance, here is the ongoing changelog for Ubuntu 12.04LTS's package, based on PHP 5.3: http://changelogs.ubuntu.com/changelogs/pool/main/p/php5/php5_5.3.10-1ubuntu3.17/changelog
If somebody were to go out of their way to install a non-default package, it's unlikely to be to include a minor change of the type we're discussing here. More likely, they would move to a newer stable branch, since the risk is only slightly higher (thanks to our minor releases being more truly minor since 5.4), and the reward much greater.
Regards,
Rowan Collins
[IMSoP]
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 andI 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 would improve things a lot for you - like parameter to some
function or returning some value that is missing. You could easily
contribute it, but if it can't go in minor version there's no point for
you to even bother. Because even if your org is super-up-to-date, they
run 5.6, most realistically - 5.5, and if it's like the majority - it'd
be 5.4 and worse. You could hope to convince your bosses and your ops to
go to 5.6 and keep it reasonably updated within 5.6, but if the only
addition you can make is 7.1, it's the lost cause - by the time your org
could go to 7.1 your project will be long done (or at least long
designed to work without this new feature) and you may be already
working in another company. Yes, we have releases (almost) each year,
but adoption of them is much slower, and with all BC breaks in 7.0 it
would probably be even slower when going from 5 to 7, so this means
doing small improvements to PHP is essentially of no practical value for
PHP developer since there's no chance this improvement can be used in
the lifetime of a typical project.
I do not think it would be good for PHP.As everything can be considered as beeing a BC break for at least
someone on Earth, I admit it is hard to understand the meaning of "small
self-contained additions in a micro version" :-pI do not think we should consider adding functions/options "BC break",
not by any sane definition of it. Of course, nothing prevents somebody
from using insane definitions, but it's of no concern to us.
The problem is always a definition question, a very subjective question.
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 add them.
About 7, yes, that's our only next release. We rejected any 5.7, so we
have to live with it.
Now, about the BC breaks, I do not see that much BC breaks for modern
apps and even WP or D7 work quite well. Let focus on that instead of
starting to using 5.6 as a solution of our frustration not being able
to move to 7, that would be terrible to have new features every patch
release. Let do not do that.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
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 add them.
No, right now you can add small enhancements to 5.5/5.6 and get it in
production in terms of months, not several years.
About 7, yes, that's our only next release. We rejected any 5.7, so we
have to live with it.
This has nothing to do with 5.7, 5.7 was proposed as BC break fodder,
not as release vehicle for adding enhancements. In any case, even if we
had 5.7, one it's released you can't add anything to it anymore, so
you're back to square one. In any case, you have to wait years for any
small enhancement to become available, unless you happen to be extremely
lucky to propose it just before the release of the next major.
Now, about the BC breaks, I do not see that much BC breaks for modern
apps and even WP or D7 work quite well. Let focus on that instead of
You know PHP world is much bigger than WP or D7, right? I've seen people
still running 5.2 in production and reluctant to go forward. Look at the
adoption figures. 5.6 is barely 1% and you propose add features into
7.1. Who'll use them - 0.0001%? People care about WP if they run WP -
but most of them run their own apps. Or an assembly of apps, all different.
starting to using 5.6 as a solution of our frustration not being able
to move to 7, that would be terrible to have new features every patch
release. Let do not do that.
It would be excellent to add new features each release. Let's do that.
You see, I can argue like you - blanket statement without any
substantiation. Can you also substantiate your position? I just did and
you rejected it with a blanket statement "no, it's terrible". No, it's
not, and the facts - including very low adoption of current versions -
support it. Until we get better adoption, I don't see how it makes any
sense to effectively ban any enhancements for 99.99% of PHP users.
Stas Malyshev
smalyshev@gmail.com
hi,
ps: please keep the "xyz wrote", makes harder to read your replies without it
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.
That one is rather easy to follow and disallow any kind of bully pushes.
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 add them.No, right now you can add small enhancements to 5.5/5.6 and get it in
production in terms of months, not several years.
Which years are you referring to?
Let put things back in perspective:
Since we introduced the release process RFC, more or less followed
correctly but lately, distributions adopt latest PHP releases much
faster. See Fedora, Debian and Ubuntu for example. I have discussed it
with a couple of maintainers (of these distros) and they all like this
new process and would like even more strictness when it comes to new
features. Why? Because it makes their work easier, be testing,
validating a new release for a LTS, etc.
So what you are saying is that now we are on track to actually improve
new releases adoption we should not make it even easier? Or go
backward by cluttering stable releases with new features? Sorry, I
cannot agree here.
About 7, yes, that's our only next release. We rejected any 5.7, so we
have to live with it.This has nothing to do with 5.7, 5.7 was proposed as BC break fodder,
not as release vehicle for adding enhancements. In any case, even if we
had 5.7, one it's released you can't add anything to it anymore, so
you're back to square one. In any case, you have to wait years for any
small enhancement to become available, unless you happen to be extremely
lucky to propose it just before the release of the next major.
You brought the "even longer with 7" argument, 5.7 could have
prevented you for having to wait "years" to get one minor features or
another. That's all.
Now, about the BC breaks, I do not see that much BC breaks for modern
apps and even WP or D7 work quite well. Let focus on that instead ofYou know PHP world is much bigger than WP or D7, right?
No comment. Pointless troll. I am the one keep saying that I do not
like us using only WP to validate changes.
I've seen people
still running 5.2 in production and reluctant to go forward. Look at the
adoption figures. 5.6 is barely 1% and you propose add features into
7.1. Who'll use them - 0.0001%? People care about WP if they run WP -
but most of them run their own apps. Or an assembly of apps, all different.
Chicken-egg problem, wait until people actually moves away from old
Debian/RHEL and adopt recent ones. This is what I am saying since long
and in the previous paragraph. Please at least try to see that.
starting to using 5.6 as a solution of our frustration not being able
to move to 7, that would be terrible to have new features every patch
release. Let do not do that.It would be excellent to add new features each release. Let's do that.
You see, I can argue like you - blanket statement without any
substantiation. Can you also substantiate your position? I just did and
you rejected it with a blanket statement "no, it's terrible". No, it's
not, and the facts - including very low adoption of current versions -
support it. Until we get better adoption, I don't see how it makes any
sense to effectively ban any enhancements for 99.99% of PHP users.
A blanket statement? We discussed that many times already, my stance
did not change a single yota since then. I repeated it here once again
to make it clear, and for the record.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
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 released versions will have to go into 7.1
once 7.0 hits release cycle, which is very close to now, arguably
already happening) and the version containing the feature (that being
7.1 as per above) is available to the contributor for their project.
Note it's not the same as "released on php.net" as upgrades take
significant time to propagate, see 1% of 5.6 adoption. Optimistically,
the delta between 7.0 and 7.1 is at least a year, and since wide
adoption of 7.1 is not likely to happen in less than a year, thus plural
"years".
with a couple of maintainers (of these distros) and they all like this
new process and would like even more strictness when it comes to new
features. Why? Because it makes their work easier, be testing,
validating a new release for a LTS, etc.
I value their effort a lot, but with all due respect I'm sorry to say
that their work being easier is a lower priority than PHP being better
for the users. If the choice is between us working harder but PHP being
better and us working less but PHP being worse, then we should choose to
work harder. Same should apply to the middlemen between us and the
users. So I can not accept the argument of "let's ban new features from
PHP until 7.1 because it makes it easier to repackage PHP". I'd be glad
to make their work easier, but not at the cost of hurting the whole
project.
So what you are saying is that now we are on track to actually improve
new releases adoption we should not make it even easier? Or go
In general, we should definitely make it easier. However, what you are
proposing is not a good way to achieve it. It's actually a terrible way
to do it, as it kills all motivation for small-scale participation and
also decreases motivation to run latest stable version for people that
need some small thing that is added only recently. Since they can't have
it in realistic timeframe, they'd work around it and since they have
already worked around it, it no longer motivates them to upgrade.
You brought the "even longer with 7" argument, 5.7 could have
prevented you for having to wait "years" to get one minor features or
another. That's all.
It would not help any, as you would ban adding small enhancements to 5.7
either (and, if I understood it correctly, 5.7 is to be 5.6 plus BC
fixes anyway), so 5.7 would be useless if I wanted to have enhancement
that might be introduced now, since, per your philosophy, 5.6 is closed
for enhancements, 5.7 is closed too since it's 5.6 + BC fixes, and 7.0
will be closed as soon as it enters release cycle, which is pretty much
any moment now. So if you want to add something like option to
json_decode, your first chance to have it is still 7.1.
No comment. Pointless troll. I am the one keep saying that I do not
like us using only WP to validate changes.
Yet you did use it as an argument, and call me a troll for pointing it
out. This is just rude.
Chicken-egg problem, wait until people actually moves away from old
Debian/RHEL and adopt recent ones. This is what I am saying since long
and in the previous paragraph. Please at least try to see that.
No, what you were saying you want to ban enhancements now (unless I
misunderstand you, then please clarify it) - not in indefinite point in
the future when our last stable adoption is not 1% but much better. When
that happens - and I hope it does, but it did not happen yet - then we
come back to this and banning enhancements in released versions and can
have the discussions with facts available then. 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 some time. So it doesn't look like not adding features makes
people to move on.
A blanket statement? We discussed that many times already, my stance
did not change a single yota since then. I repeated it here once again
to make it clear, and for the record.
Saying something many times is not the same as substantiating it. In the
last letter you did finally bring an argument for banning enhacements -
it makes the life of third-party packagers easier. It is completely
true, but it carries a very high price, and we should not pay this
price. I'm all for any effort that makes their lives easier, but with
the condition that it does not mean something as drastic as not allowing
small enhancements, which was always allowed since we started the whole
release process thing.
Stas Malyshev
smalyshev@gmail.com
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 some time. So it doesn't look like not adding features makes
people to move on.
Practical example.
I still have several sites on 5.2 hosting. They need upgrading before
they will run on 5.4 ... and while they would work on 5.3 with warnings
switched off there is no point making that switch. They HAVE to be
modified for 5.4, and that takes time :(
Retesting all of the 5.4 stuff on a later version will wait until
everything is on 5.4!
None of these 'small self-contained additions' have any use in
maintaining the existing sites, and so there is little point even
bothering with 5.5 or 5.6 if 7.0 is going to be out before the last of
the 5.2 sites have been upgraded. Hence my development server having
both 5.4 and 7.0 running in parallel. Yes 5.6-latest is a third option
on that but only until 7.0 IS released.
Th switch to 7.0 will not be because of the 'new additions'. Even type
hinting will only be a hindrance to be lived with rather than a 'must
have' feature simply because it does nothing to help the real problems
of data validation! That code is already present and working. The ONLY
reason for moving forward is to keep what is currently working perfectly
on 5.2 still working on a later version. Renaming everything to some new
standard gives nothing but restoring the performance improvements that
eaccelerator currently provides is another holding up a move from 5.4 ...
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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 released versions will have to go into 7.1
once 7.0 hits release cycle, which is very close to now, arguably
already happening) and the version containing the feature (that being
7.1 as per above) is available to the contributor for their project.
Note it's not the same as "released on php.net" as upgrades take
significant time to propagate, see 1% of 5.6 adoption. Optimistically,
the delta between 7.0 and 7.1 is at least a year, and since wide
adoption of 7.1 is not likely to happen in less than a year, thus plural
"years".with a couple of maintainers (of these distros) and they all like this
new process and would like even more strictness when it comes to new
features. Why? Because it makes their work easier, be testing,
validating a new release for a LTS, etc.I value their effort a lot, but with all due respect I'm sorry to say
that their work being easier is a lower priority than PHP being better
for the users.
How many % use source install vs packages? From which users are we
talking about here?
If the choice is between us working harder but PHP being
better and us working less but PHP being worse, then we should choose to
work harder. Same should apply to the middlemen between us and the
users. So I can not accept the argument of "let's ban new features from
PHP until 7.1 because it makes it easier to repackage PHP". I'd be glad
to make their work easier, but not at the cost of hurting the whole
project.
It is one of many arguments. Do not forget the other ones, which are
as valid and important than the distros one.
So what you are saying is that now we are on track to actually improve
new releases adoption we should not make it even easier? Or goIn general, we should definitely make it easier. However, what you are
proposing is not a good way to achieve it. It's actually a terrible way
to do it, as it kills all motivation for small-scale participation and
also decreases motivation to run latest stable version for people that
need some small thing that is added only recently. Since they can't have
it in realistic timeframe, they'd work around it and since they have
already worked around it, it no longer motivates them to upgrade.
What killed it was to reject 5.7, this was a mistake based on nothing
but some random fears about not being able to finish 7 "in time". To
make 5.6 the "all in" small features improvements in every 2nd patch
releases for the next year is going to be good fun, for everyone.
Remember? 3 years, that means we have a year to get all possible small
improvements in. It cannot end well imho :)
You brought the "even longer with 7" argument, 5.7 could have
prevented you for having to wait "years" to get one minor features or
another. That's all.It would not help any, as you would ban adding small enhancements to 5.7
either (and, if I understood it correctly, 5.7 is to be 5.6 plus BC
fixes anyway), so 5.7 would be useless if I wanted to have enhancement
that might be introduced now, since, per your philosophy, 5.6 is closed
for enhancements, 5.7 is closed too since it's 5.6 + BC fixes, and 7.0
will be closed as soon as it enters release cycle, which is pretty much
any moment now. So if you want to add something like option to
json_decode, your first chance to have it is still 7.1.
I was against not having 5.7, and against 5.7 only for notices (sadly
the RFC did not contain any other options despite agreements on that).
My reasoning back then and this discussion proves it correct, is that
we will make a mess of 5.6 because "7 adoption will be even slower".
Solving zero of these issues but making 7.x adoption even slower and
5.6.x a features check mess. Not my idea of simplicity or not the best
way to increase adoption by helping users and packagers/distros.
Chicken-egg problem, wait until people actually moves away from old
Debian/RHEL and adopt recent ones. This is what I am saying since long
and in the previous paragraph. Please at least try to see that.No, what you were saying you want to ban enhancements now (unless I
misunderstand you, then please clarify it) - not in indefinite point in
the future when our last stable adoption is not 1% but much better. When
that happens - and I hope it does, but it did not happen yet - then we
come back to this and banning enhancements in released versions and can
have the discussions with facts available then. 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 some time. So it doesn't look like not adding features makes
people to move on.
Again, see that when people moves to latest distributions versions as
well. Distributions catch up recently with our release process and
only latest releases have latest PHP. So yes, I do think adding
enhancement in patch releases is counter productive.
A blanket statement? We discussed that many times already, my stance
did not change a single yota since then. I repeated it here once again
to make it clear, and for the record.Saying something many times is not the same as substantiating it. In the
last letter you did finally bring an argument for banning enhacements -
it makes the life of third-party packagers easier.
No. Not only 3rd parties packagers. Users too. Not "which patch
version has that?" hell. I said the atter many times too, including in
this thread.
It is completely
true, but it carries a very high price, and we should not pay this
price.
So you consider adoption the bigger issue here but one of the best way
to actually increase the adoption pace is not worth it? Distributions
actually providing latest PHP is what boosts adoption.
I'm all for any effort that makes their lives easier, but with
the condition that it does not mean something as drastic as not allowing
small enhancements, which was always allowed since we started the whole
release process thing.
And it went too far for my taste.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
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
https://github.com/php/php-src/pull/969
and of course there are a bunch of similar ones from other people, and
there are cases when somebody simply pushes a change like that, other times
somebody points out that it should require an RFC(
https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
most of the times we simply don't know what to do, and eventually we just
let the PR/patch to rot and die.
I would like to know if we can come up with a rule which can have consensus
behind it, and maybe formalize it as an extension to our current
releaseprocess rfc.
I personally do not want to see any features go into a patch release
(the Z in X.Y.Z). It's not just a pain to document, but there's no
real reason to do this because we have minor releases (the Y in X.Y.Z)
each year.
I'd even like to tighten up on what "bug fixes" we allow into patch
releases, as I think we have been far too accepting in the past.
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.
Adding an option I think it's ok provided it's not controversial and not
an attempt to create entirely different large functionality hidden
behind the option (e.g. "let's add an option to make mysql_connect also
connect to Postgres databases"). If it's something that clearly a small
functional piece that is missing, adding it I think is OK. If it's
bigger (like entirely new functionality or substantial change in
existing one) then it'd be better to go into next version.
I would like to know if we can come up with a rule which can have
consensus behind it, and maybe formalize it as an extension to our
current releaseprocess rfc.
I'm not sure there's a formal rule that would be good for all cases. We
can have guidelines but unless we reject all changes completely (which I
strongly disagree with) I think we'll still have to consider them on the
substance.
Stas Malyshev
smalyshev@gmail.com
On Mon, Mar 30, 2015 at 10:52 PM, Stanislav Malyshev smalyshev@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.Adding an option I think it's ok provided it's not controversial and not
an attempt to create entirely different large functionality hidden
behind the option (e.g. "let's add an option to make mysql_connect also
connect to Postgres databases"). If it's something that clearly a small
functional piece that is missing, adding it I think is OK. If it's
bigger (like entirely new functionality or substantial change in
existing one) then it'd be better to go into next version.I would like to know if we can come up with a rule which can have
consensus behind it, and maybe formalize it as an extension to our
current releaseprocess rfc.I'm not sure there's a formal rule that would be good for all cases. We
can have guidelines but unless we reject all changes completely (which I
strongly disagree with) I think we'll still have to consider them on the
substance.
even agreeing upon something like adding features in a micro version needs
a format RFC and a 2/3 vote would allow us to have a conservative default
while we could still make exceptions with a clear process to follow.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
even agreeing upon something like adding features in a micro version
needs a format RFC and a 2/3 vote would allow us to have a conservative
default while we could still make exceptions with a clear process to follow.
I'm still not sure which problem we're trying to solve. Can someone give
me 3-4 examples of some important code that was in the past broken by
adding option to json_decode or get_headers or creating a function like
get_error_handler?
--
Stas Malyshev
smalyshev@gmail.com
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:
https://github.com/php/php-src/pull/1204
https://github.com/php/php-src/pull/969
and of course there are a bunch of similar ones from other people, and
there are cases when somebody simply pushes a change like that, other times
somebody points out that it should require an RFC(
https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
most of the times we simply don't know what to do, and eventually we just
let the PR/patch to rot and die.
I would like to know if we can come up with a rule which can have consensus
behind it, and maybe formalize it as an extension to our current
releaseprocess rfc.
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 decisions in the long run.
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 clean solution
inside the DateTimeInterface seems closed forever.
Besides, I think that the vast majority of PHP users out there is using
distro versions, so it does not matter to them if a feature goes into
5.6.7 oder 7.1.0, they will get the feature when the distro upgrades.
But for the distro package maintainers and the users it would be a lot
easier if e.g. the debian version could just be the latest patch version
and not a mix of several versions after their package freeze.
So, please let the x.y.z versions contain only additional (security)
fixes and stick to the RFC process, thanks.
Greets
Dennis
De : Dennis Birkholz [mailto:dennis@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 decisions in the long run.
Correct. The "small self-contained changes" concept easily leads to the rules not being the same for everyone.
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 clean solution
inside the DateTimeInterface seems closed forever.
This example is clearly an RFC released as a PR to bypass the rules (discussion, vote, and feature freeze date). I don't understand why it was accepted and merged. Can someone give the rule that was followed in this case ? If it should have gone through an RFC, can we revert the change and send him back to the RFC process ?
Regards
François
De : Dennis Birkholz [mailto:dennis@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 decisions in the long run.Correct. The "small self-contained changes" concept easily leads to the
rules not being the same for everyone.
this is what I feel, and one of the reasons for starting this thread.
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 clean solution
inside the DateTimeInterface seems closed forever.This example is clearly an RFC released as a PR to bypass the rules
(discussion, vote, and feature freeze date). I don't understand why it was
accepted and merged. Can someone give the rule that was followed in this
case ? If it should have gone through an RFC, can we revert the change and
send him back to the RFC process ?
https://wiki.php.net/rfc/releaseprocess
"No feature addition after final x.y.0 release (or x.0.0). Self contained
features or new SAPIs could be carefully considered on a case by case
basis."
"Bugfixes only (with a room for exceptions on a case by case basis and only
for small self contained features additions)."
The problem is that there is no definition/explanation for the case-by-case
basis.
Does it need a vote? Does it need prior discussion on the thread? Does it
need explicit approval from the RMs?
This problem was brought up in the past a couple of times (the
releaseprocess RFC being too vague here and there also this specific issue
about not having an agreed upon workflow for the approval process for micro
versions), but no resolution was reached so there are examples where we
have lengthly discussion and fullblown RFC for adding a new constant option
to json_encode() while some other feature request just gets merged by an RM
or maintainer of that given extension.
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 process work.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
De : Ferenc Kovacs [mailto:tyra3l@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 process work.
The release process document is clear : "New features or additions to the core should go through the RFC process." (hopefully considering the 'core' as the whole PHP distribution). It would be better using "must" instead of "should" but it is quite clear.
So, providing "a room for exceptions on a case by case basis and only for small self-contained features and additions" does not mean that these features don't have to go through an RFC. There is nothing to add to the rules, we just need to have them enforced by people who currently merge new features without demanding an approved RFC. If everyone respects the rules, the 'case by case process' is clear, it means 'approved through an RFC'. Only bug fixes with no side effect can be merged without an RFC.
So, once again, as https://github.com/php/php-src/pull/1145 clearly did not follow the rules and was not approved in any way, I'm asking whoever merged it to revert the change and ask the author to go through an RFC.
Regards
François
De : Ferenc Kovacs [mailto:tyra3l@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 process work.The release process document is clear : "New features or additions to the
core should go through the RFC process." (hopefully considering the 'core'
as the whole PHP distribution). It would be better using "must" instead of
"should" but it is quite clear.
I see your point, but the consensus/status quo(based on past mailing list
discussion and( is/was that not everything requires an RFC.
So, providing "a room for exceptions on a case by case basis and only for
small self-contained features and additions" does not mean that these
features don't have to go through an RFC. There is nothing to add to the
rules, we just need to have them enforced by people who currently merge new
features without demanding an approved RFC. If everyone respects the rules,
the 'case by case process' is clear, it means 'approved through an RFC'.
Only bug fixes with no side effect can be merged without an RFC.
again, I'm fine with changing the current status quo, but we can't pretend
that this was always the consensus when we were doing otherwise and >95% of
the people seemed to be okay with it (I had a couple of threads in the past
years where I tried to clarify a couple of things about the voting and
releaseprocess rfcs, but nothing really come out of it).
So, once again, as https://github.com/php/php-src/pull/1145 clearly did
not follow the rules and was not approved in any way, I'm asking whoever
merged it to revert the change and ask the author to go through an RFC.
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.
For the record this was merged by Stas:
http://git.php.net/?p=php-src.git;a=commitdiff;h=cc2fd00942d59975326166be70cd36da85a681d3
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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 mentioning he is
explicitly against. Could you point me to where he describes he is
against it? If you think it needs to be reverted please do so, you are
the 5.6 RM. If you want me to do it I can do it later (on the weekend)
but you'll have to update the RC branch.
--
Stas Malyshev
smalyshev@gmail.com
On Wed, Apr 1, 2015 at 9:38 PM, Stanislav Malyshev smalyshev@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 to
agree with the revert.Derick reviewed that patch and I didn't see him even mentioning he is
explicitly against. Could you point me to where he describes he is
against it? If you think it needs to be reverted please do so, you are
the 5.6 RM. If you want me to do it I can do it later (on the weekend)
but you'll have to update the RC branch.
you already stated that you missed Derick's mail, so I won't comment on
that, but only the revert part:
I'm able and willing to revert stuff when needed, but I always assume good
faith (and that was the case here) and prefer contacting the author first
if there is time pressure to revert.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
De : Ferenc Kovacs [mailto:tyra3l@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 process work.The release process document is clear : "New features or additions to the core should go through the RFC process." (hopefully considering the 'core' as the whole PHP distribution). It would be better using "must" instead of "should" but it is quite clear.
So, providing "a room for exceptions on a case by case basis and only for small self-contained features and additions" does not mean that these features don't have to go through an RFC. There is nothing to add to the rules, we just need to have them enforced by people who currently merge new features without demanding an approved RFC. If everyone respects the rules, the 'case by case process' is clear, it means 'approved through an RFC'. Only bug fixes with no side effect can be merged without an RFC.
So, once again, as https://github.com/php/php-src/pull/1145 clearly did not follow the rules and was not approved in any way, I'm asking whoever merged it to revert the change and ask the author to go through an RFC.
It’s not a secret that I’m not a big fan of too much bureaucracy, we’re still humans that can discuss and argue without a formal RFC.
If anything develops to be controversial, let’s go through an RFC, if not, then fine and let them go ahead.
Hi,
De : Ferenc Kovacs [mailto:tyra3l@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 process work.The release process document is clear : "New features or additions to
the core should go through the RFC process." (hopefully considering the
'core' as the whole PHP distribution). It would be better using "must"
instead of "should" but it is quite clear.So, providing "a room for exceptions on a case by case basis and only
for small self-contained features and additions" does not mean that these
features don't have to go through an RFC. There is nothing to add to the
rules, we just need to have them enforced by people who currently merge new
features without demanding an approved RFC. If everyone respects the rules,
the 'case by case process' is clear, it means 'approved through an RFC'.
Only bug fixes with no side effect can be merged without an RFC.So, once again, as https://github.com/php/php-src/pull/1145 clearly did
not follow the rules and was not approved in any way, I'm asking whoever
merged it to revert the change and ask the author to go through an RFC.It’s not a secret that I’m not a big fan of too much bureaucracy, we’re
still humans that can discuss and argue without a formal RFC.
If anything develops to be controversial, let’s go through an RFC, if not,
then fine and let them go ahead.
I agree here. I think that we should definitely email to the internals
about any small addition (self-contained constant or function) and if there
are no objection and everyone agrees that it's a good idea, then I don't
think we need RFC.
Cheers
Jakub
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 clean solution
inside the DateTimeInterface seems closed forever.
Why is it closed forever? I've seen Derick look at the patch and didn't
see any objection from him except for small CS fixes. Also, we did not
release it yet so if there's any problem with it it still can be
reverted. But I haven't seen any mention of it so far on the list except
for this mention in completely unrelated topic which would be extremely
easy to miss and that says basically "all is lost now, no use to discuss
it, the end is nigh" without explaining anything. If you want to explain
yourself, please start a topic and do this, we have 2 weeks before
5.6.8, ample time to revert if necessary.
Besides, I think that the vast majority of PHP users out there is using
distro versions, so it does not matter to them if a feature goes into
5.6.7 oder 7.1.0, they will get the feature when the distro upgrades.
That'd basically mean "never", no distro would go from 5.6 to 7.1 within
the same version, and changing distro version is insanely operationally
complex thing which is done very rarely.
So, please let the x.y.z versions contain only additional (security)
fixes and stick to the RFC process, thanks.
We are already doing this. The discussion is about changing the process
to ban enhancements in released versions, which was never the case and
we specifically emphasized this when we started it. Now you seem to
propose to ban non-security bugfixes on releases too. So basically you'd
have to wait for years to even get a bug fixed. Nice.
--
Stas Malyshev
smalyshev@gmail.com
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 will not
reproduce the arguments here but now the door for a clean solution
inside the DateTimeInterface seems closed forever.Why is it closed forever? I've seen Derick look at the patch and didn't
see any objection from him except for small CS fixes. Also, we did not
release it yet so if there's any problem with it it still can be
reverted. But I haven't seen any mention of it so far on the list except
for this mention in completely unrelated topic which would be extremely
easy to miss and that says basically "all is lost now, no use to discuss
it, the end is nigh" without explaining anything. If you want to explain
yourself, please start a topic and do this, we have 2 weeks before
5.6.8, ample time to revert if necessary.
the discussion appeared on the list at the 5th of march:
http://markmail.org/message/3aesaaoqv6ihiw53
The thing with this patch is, there should be one factory method for
each classes implementing DateTimeInterface to create an instance from
any other instance of DateTimeInterface. Having some factory methods for
some reference objects is just inconsistent.
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.
Besides, I think that the vast majority of PHP users out there is using
distro versions, so it does not matter to them if a feature goes into
5.6.7 oder 7.1.0, they will get the feature when the distro upgrades.That'd basically mean "never", no distro would go from 5.6 to 7.1 within
the same version, and changing distro version is insanely operationally
complex thing which is done very rarely.
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.
So, please let the x.y.z versions contain only additional (security)
fixes and stick to the RFC process, thanks.We are already doing this. The discussion is about changing the process
to ban enhancements in released versions, which was never the case and
we specifically emphasized this when we started it. Now you seem to
propose to ban non-security bugfixes on releases too. So basically you'd
have to wait for years to even get a bug fixed. Nice.
No, I don't say ban non-security bugfixes. But I say don't add new
methods/functionality that should go in the next feature release.
Thanks
Dennis
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 version from php.net of the
same minor. I've seen it done many times. It's next to impossible to
make the same with different major, and nobody would do it for obvious
stability concerns. I think the approach of "you have to wait several
years for any tiny change" is terrible and detrimental for PHP
development, however easy it makes the life of folks in Debian, etc.
No, I don't say ban non-security bugfixes. But I say don't add new
methods/functionality that should go in the next feature release.
I'm fine with adding only those that should go into the current one,
namely small self-contained additions :) Just as we agreed on long ago.
Stas Malyshev
smalyshev@gmail.com
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 said, it is
very easy to make .rpm or .deb with source version from php.net of the
same minor. I've seen it done many times. It's next to impossible to
make the same with different major, and nobody would do it for obvious
stability concerns. I think the approach of "you have to wait several
years for any tiny change" is terrible and detrimental for PHP
development, however easy it makes the life of folks in Debian, etc.
I vaguely remembered the usage statistics that Anthony assembled in
December and had other numbers in my head. (see
http://blog.ircmaxell.com/2014/12/php-install-statistics.html)
5.5.12 (Ubuntu 14.10): 0.16%
5.5.9 (Ubuntu 14.04): 1.81%
5.4.16 (CentOS 7.0): 0.42%
5.4.4 (Debian Wheezy): 2.14%
5.3.10 (Ubuntu 12.04): 4.13%
5.3.3 (Debian Squeeze, Centos 6.6): 10.37%
5.3.2 (Ubuntu 10.04): 1.06%
5.1.6 (CentOS 5.11): 1.14%
Debian, Ubuntu and CentOS: ~21,23%
(I assume here like Anthony that the installs matching a distribution
specific version always come from that distribution).
So I have to step a little back from my previous statement, only about
1/5th of the installs seem to use distribution installs. But there are a
lot of used versions in between. Why they don't upgrade I don't know,
but if the upgrade would be a no-brainer without any risk for
incompatibility, probably more would upgrade, but that is just speculation.
No, I don't say ban non-security bugfixes. But I say don't add new
methods/functionality that should go in the next feature release.I'm fine with adding only those that should go into the current one,
namely small self-contained additions :) Just as we agreed on long ago.
An addition and a bug fix are different things.
Greets
Dennis
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 follow
the flow of the addition of the similar method
DateTimeImmutable::createFromMutable() that was added, without RFC
(correct me if I'm wrong), in 5.6.0:
http://php.net/manual/en/datetimeimmutable.createfrommutable.php
Unfortunately, I'm not a huge fan of Derick's createFromMutable() method
(why isn't there just a createFromInstance() or copy() method of some
sort), but I tried to best follow the current design with my proposal and
pull request.
I think some clarification regarding what does or does-not require an RFC
would make it much more helpful to contributors that want to help build PHP.
Again, sorry if I caused any issue here.
- Trevor
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 said, it is
very easy to make .rpm or .deb with source version from php.net of the
same minor. I've seen it done many times. It's next to impossible to
make the same with different major, and nobody would do it for obvious
stability concerns. I think the approach of "you have to wait several
years for any tiny change" is terrible and detrimental for PHP
development, however easy it makes the life of folks in Debian, etc.I vaguely remembered the usage statistics that Anthony assembled in
December and had other numbers in my head. (see
http://blog.ircmaxell.com/2014/12/php-install-statistics.html)5.5.12 (Ubuntu 14.10): 0.16%
5.5.9 (Ubuntu 14.04): 1.81%
5.4.16 (CentOS 7.0): 0.42%
5.4.4 (Debian Wheezy): 2.14%
5.3.10 (Ubuntu 12.04): 4.13%
5.3.3 (Debian Squeeze, Centos 6.6): 10.37%
5.3.2 (Ubuntu 10.04): 1.06%
5.1.6 (CentOS 5.11): 1.14%Debian, Ubuntu and CentOS: ~21,23%
(I assume here like Anthony that the installs matching a distribution
specific version always come from that distribution).So I have to step a little back from my previous statement, only about
1/5th of the installs seem to use distribution installs. But there are a
lot of used versions in between. Why they don't upgrade I don't know,
but if the upgrade would be a no-brainer without any risk for
incompatibility, probably more would upgrade, but that is just speculation.No, I don't say ban non-security bugfixes. But I say don't add new
methods/functionality that should go in the next feature release.I'm fine with adding only those that should go into the current one,
namely small self-contained additions :) Just as we agreed on long ago.An addition and a bug fix are different things.
Greets
Dennis
Damn Gmail... I just top-posted. I'm going to go away for a while now...
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 follow
the flow of the addition of the similar method
DateTimeImmutable::createFromMutable()that was added, without RFC
(correct me if I'm wrong), in 5.6.0:
http://php.net/manual/en/datetimeimmutable.createfrommutable.phpUnfortunately, I'm not a huge fan of Derick's
createFromMutable()
method (why isn't there just acreateFromInstance()orcopy()method of
some sort), but I tried to best follow the current design with my proposal
and pull request.I think some clarification regarding what does or does-not require an RFC
would make it much more helpful to contributors that want to help build PHP.Again, sorry if I caused any issue here.
- Trevor
On Wed, Apr 1, 2015 at 4:09 PM Dennis Birkholz dennis@birkholz.biz
wrote: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 said, it is
very easy to make .rpm or .deb with source version from php.net of the
same minor. I've seen it done many times. It's next to impossible to
make the same with different major, and nobody would do it for obvious
stability concerns. I think the approach of "you have to wait several
years for any tiny change" is terrible and detrimental for PHP
development, however easy it makes the life of folks in Debian, etc.I vaguely remembered the usage statistics that Anthony assembled in
December and had other numbers in my head. (see
http://blog.ircmaxell.com/2014/12/php-install-statistics.html)5.5.12 (Ubuntu 14.10): 0.16%
5.5.9 (Ubuntu 14.04): 1.81%
5.4.16 (CentOS 7.0): 0.42%
5.4.4 (Debian Wheezy): 2.14%
5.3.10 (Ubuntu 12.04): 4.13%
5.3.3 (Debian Squeeze, Centos 6.6): 10.37%
5.3.2 (Ubuntu 10.04): 1.06%
5.1.6 (CentOS 5.11): 1.14%Debian, Ubuntu and CentOS: ~21,23%
(I assume here like Anthony that the installs matching a distribution
specific version always come from that distribution).So I have to step a little back from my previous statement, only about
1/5th of the installs seem to use distribution installs. But there are a
lot of used versions in between. Why they don't upgrade I don't know,
but if the upgrade would be a no-brainer without any risk for
incompatibility, probably more would upgrade, but that is just
speculation.No, I don't say ban non-security bugfixes. But I say don't add new
methods/functionality that should go in the next feature release.I'm fine with adding only those that should go into the current one,
namely small self-contained additions :) Just as we agreed on long ago.An addition and a bug fix are different things.
Greets
Dennis
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 it without noticing the internals thread regarding it) as
an example. I hope this does not prevent you from contributing in the
future.
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 follow
the flow of the addition of the similar method
DateTimeImmutable::createFromMutable()that was added, without RFC
(correct me if I'm wrong), in 5.6.0:
http://php.net/manual/en/datetimeimmutable.createfrommutable.php
I think DateTimeInterface and DateTimeImmutable where added in 5.6, but
I don't know if there was some RFC for that, I did not follow the
internals list back then.
Unfortunately, I'm not a huge fan of Derick's
createFromMutable()method
(why isn't there just acreateFromInstance()orcopy()method of some
sort), but I tried to best follow the current design with my proposal and
pull request.
I would really like you to create an RFC that uses a single method in
the DateTimeInterface for this kind of cloning.
Greets
Dennis
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 repackage it to use
the source from the same minor but up-to-date patch version.
An addition and a bug fix are different things.
I know but you said, I'm quoting, "please let the x.y.z versions contain
only additional (security) fixes" which excluding non-security fixes too.
Let's consider a somewhat arbitrary example:
https://github.com/php/php-src/pull/1211
There's a HTTP status code needs to be added (doesn't matter if new or
just omitted by oversight). You could have it in next 5.6 version (you
can have it in use in 3 months realistically - one month for release to
catch up, 2 months for ops in your project to be confident that new
patch release doesn't break anything) or you could have it in 2.5 years
(1.5 years for 7.1 to be released, 1 year - and that's extremely
optimistic - for ops to be ok to switch to a new distro version which
hopefully - just hopefully, extremely optimistic again - but that time
ships with 7.1 and not still randomly patched 5.5).
For me, it sounds insane that you'd have to wait for so long for such a
simple thing.
Of course, instead of status code it could be option support in XML, or
new function/option support in ICU, or new connection option in mysql.
Any improvement in the environment - do you want it in PHP in terms of
several years or in terms of 3 months?
I foresee what it would turn into is arguing "well, not supporting
option X is really a bug so that's a bugfix!" which only will lead to
more chaos and argument.
Stas Malyshev
smalyshev@gmail.com
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 I said, it's very easy to take distro package and repackage it to use
the source from the same minor but up-to-date patch version.
As I said, I miss-remembered the numbers to be much higher.
An addition and a bug fix are different things.
I know but you said, I'm quoting, "please let the x.y.z versions contain
only additional (security) fixes" which excluding non-security fixes too.
I tried to indicate with braces around security that general
non-security fixes may be allowed to, but I try to be more explicit next
time ;-)
Let's consider a somewhat arbitrary example:
https://github.com/php/php-src/pull/1211There's a HTTP status code needs to be added (doesn't matter if new or
just omitted by oversight). You could have it in next 5.6 version (you
can have it in use in 3 months realistically - one month for release to
catch up, 2 months for ops in your project to be confident that new
patch release doesn't break anything) or you could have it in 2.5 years
(1.5 years for 7.1 to be released, 1 year - and that's extremely
optimistic - for ops to be ok to switch to a new distro version which
hopefully - just hopefully, extremely optimistic again - but that time
ships with 7.1 and not still randomly patched 5.5).
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?
if any of this is true, I would consider the patch not self-contained
any more.
For me, it sounds insane that you'd have to wait for so long for such a
simple thing.Of course, instead of status code it could be option support in XML, or
new function/option support in ICU, or new connection option in mysql.
Any improvement in the environment - do you want it in PHP in terms of
several years or in terms of 3 months?
But then using the x.y.z version schema implies something like semver
but in reality we have more like a rolling release.
Instead we should consider having a stable "PHP-next" nightly release
that is something like a stabilized master that gets all changes for the
X.Y+1 release. If you require these little features, you use that, if
you only require security/bug fixes, you stick to the regular x.y.z
releases.
Greets
Dennis
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 are OK, others are not OK. This has been the case since
we started the whole format release process thing.
If you agree with that, then our positions are completely the same.
However, it's not what Pierre's (and possibly others) position is - that
position does not ask any questions, it's a blanket ban on any
enhancement, without any consideration or looking into the substance of
the enhancement. If it adds anything that did not exist before, however
minor and safe, it is still banned.
But then using the x.y.z version schema implies something like semver
No it doesn't. People used versions way before semver was even a thing,
and semver does not owns versioning in any way. There are literally
hundreds if not thousands of projects using this version format without
any relation to semver. We may reuse the rules semver uses, when it
makes sense to us, but using three-component version does not introduce
any obligation to abide by what semver.org says to the letter.
Instead we should consider having a stable "PHP-next" nightly release
that is something like a stabilized master that gets all changes for the
X.Y+1 release. If you require these little features, you use that, if
Who will be doing that? Who will be doing all the necessary backporting
and maintenance and how it's different from just porting stable changes
to stable version?
--
Stas Malyshev
smalyshev@gmail.com
Stanislav Malyshev wrote:
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 are OK, others are not OK. This has been the case since
we started the whole format release process thing.
Hmm, would you consider introducing a new function in the global
namespace to be a self-contained feature? I would not, because the
function definition would change the global environment, possibly
breaking some code.
--
Christoph M. Becker
Hi!
Hmm, would you consider introducing a new function in the global
namespace to be a self-contained feature? I would not, because the
Depends on the function. It it's properly prefixed and does not rely or
disrupt anything else then yes. Otherwise, no.
function definition would change the global environment, possibly
breaking some code.
You can always invent some code that depends on exact state of the
universe in the moment (https://xkcd.com/1172/) but let's be reasonable
- if somebody stuck their function into intl_* or mysql_* namespace
whatever happens next is on them.
--
Stas Malyshev
smalyshev@gmail.com
Stanislav Malyshev wrote:
Hmm, would you consider introducing a new function in the global
namespace to be a self-contained feature? I would not, because theDepends on the function. It it's properly prefixed and does not rely or
disrupt anything else then yes. Otherwise, no.
But what is "properly prefixed"? Is there a list of reserved prefixes?
function definition would change the global environment, possibly
breaking some code.You can always invent some code that depends on exact state of the
universe in the moment (https://xkcd.com/1172/) but let's be reasonable
- if somebody stuck their function into intl_* or mysql_* namespace
whatever happens next is on them.
I agree. However, there are other "namespaces" which are not so
special, especially for beginners, for instance, array_* and str_*. And
of course, someone might consider it to be reasonable to invent a new
function in userland which is an extension of some existing function,
therefore giving it a similar name, e.g. preg_replace_callback_array().
Would that be considered to be bad style? If so, where is it documented?
I'm aware that I'm nit-picking, and that the probability of such
collisions is near zero, but it is not equal to zero.
--
Christoph M. Becker
Hi!
But what is "properly prefixed"? Is there a list of reserved prefixes?
Yes, it's called the manual :)
I agree. However, there are other "namespaces" which are not so
special, especially for beginners, for instance, array_* and str_*. And
Adding something like strlen() in core now probably would be dangerous.
array_* OTOH should be obvious as reserved. Just follow common sense -
if you prefix your function the same way as a function group in the
manual, then you're in trouble.
of course, someone might consider it to be reasonable to invent a new
function in userland which is an extension of some existing function,
therefore giving it a similar name, e.g.preg_replace_callback_array().
Someone would be wrong then.
Would that be considered to be bad style? If so, where is it documented?
Yes. It is common sense. Not everything has to be spelled out to be
true, and I think rule lawyering and ignoring common sense is not going
to help anybody here. If you don't understand that adding preg_*
function in global namespace that looks like existing core function is a
bad idea, maybe some mentorship by more experienced developer is in order.
I'm aware that I'm nit-picking, and that the probability of such
collisions is near zero, but it is not equal to zero.
If we limit ourselves only to changes that have exactly zero chance of
affecting somebody's work however weird and broken that is, we may as
well pack our things and go home, because we'd never do anything at all.
I'm feeling that I am arguing with more and more bizzare scenarios
invented for the purpose to arrive at predetermined conclusion instead
of determining conclusion by real scenarios that sane developers do.
Stas Malyshev
smalyshev@gmail.com
Would that be considered to be bad style? If so, where is it
documented?Yes. It is common sense. Not everything has to be spelled out to be
true, and I think rule lawyering and ignoring common sense is not going
to help anybody here. If you don't understand that adding preg_*
function in global namespace that looks like existing core function is
a
bad idea, maybe some mentorship by more experienced developer is in
order.
I think you go much too far here: yes, adding a function designed to look like a core one should be considered carefully, but I don't think it's "insane" or a sign that a user "needs mentoring by someone more experienced".
It's equally "common sense" to assume that if I look at the manual and it says a function doesn't exist in PHP 5.6, it will continue to not exist unless I adopt a new version. If I then run "apt-get upgrade" and find (as you have expressed a wish for) that it brings in a new patch version of PHP, I'm unlikely to think of this as "adopting a new version of PHP". I think surprise at finding a whole new function conflicting with mine would be a perfectly sane reaction.
Now, as I've said before, I think the compromise of allowing such additions in the current stable branch is probably sensible. But justifying this by insulting users who don't think of the global namespace as reserved is not helpful. The fact is there is no (used) reserved namespace in PHP; if we can remedy that, this whole line of argument becomes moot.
Regards,
Rowan Collins
[IMSoP]
De : Stanislav Malyshev [mailto:smalyshev@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 - enhancements that are a) small and b)
self-contained are OK, others are not OK. This has been the case since
we started the whole format release process thing.
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 anymore.
One example : https://wiki.php.net/rfc/cyclic-replace can probably be considered as a 'small self-contained' addition. Should I continue with the RFC, respecting feature freeze and proposing it for 7.1, or should I just ask the PR to be merged in 7.0 ? If it is accepted by a vote, can it still go to 7.0 ? It is really not clear to me.
Regards
François
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 new x.y.0 release is ready, x.y-1.z releases should receive bug fixes only. Thus 5.5.x should not be receiving features.
Trying to develop several versions of PHP in parallel causes the
confusion. If users want new features there is an obvious way for them
to get them; upgrade their version of PHP.
Levi Morrison wrote:
It's not just a pain to document, but there's no
real reason to do this because we have minor releases (the Y in X.Y.Z)
each year.
This is only true for the past couple of years. This needs to be a
separate conversation but if we're going to continue to release a new
minor version each year, and we continue to drop support for previous
versions, it is a dramatic change to the support lifecycle for PHP.
Getting people to upgrade from an ancient version of PHP to a much
better PHP 5.4 is acceptable as we can say that it's a much better
version of PHP. Forcing people to upgrade from 7.0 to 7.3, when it
will only be an incremental improvement is going to have much more
resistance from users.
Because of that, I think we may feel pressure to slow down the change
in minor version numbers. I also just don't seem a problem in adding
functions in patch versions, so long as there is no BC break.
One example : https://wiki.php.net/rfc/cyclic-replace can probably be considered as a 'small self-contained' addition. Should I continue with the RFC, respecting feature freeze and proposing it for 7.1, or should I just ask the PR to be merged in 7.0 ?
During the discussion of the RFC, several people voiced opposition to it.
Nikita Popov wrote:
I'm against this RFC. Not because I don't like the implementation or
similar, I simply don't consider this functionality to be sufficiently
important to warrant both the additional internal complexity it adds and
the complexity it adds to our user-facing API.
So I think this does need an RFC to allow people to vote properly.
And yes, I think the preg_replace_callback_array addition probably
should have gone to a vote. I know some people have stated objections
about having too many RFCs - but I think that having a small hurdle to
adding stuff to core is not a bad thing. If nothing else, it forces
people to think and describe the changes clearly.
cheers
Dan
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 new x.y.0 release is ready, x.y-1.z releases should receive bug
fixes only. Thus 5.5.x should not be receiving features.Trying to develop several versions of PHP in parallel causes the
confusion. If users want new features there is an obvious way for them
to get them; upgrade their version of PHP.
+1 This is exactly it. The longer older versions are "supported" the longer
they remain in the wild.
Levi Morrison wrote:
It's not just a pain to document, but there's no
real reason to do this because we have minor releases (the Y in X.Y.Z)
each year.This is only true for the past couple of years. This needs to be a
separate conversation but if we're going to continue to release a new
minor version each year, and we continue to drop support for previous
versions, it is a dramatic change to the support lifecycle for PHP.Getting people to upgrade from an ancient version of PHP to a much
better PHP 5.4 is acceptable as we can say that it's a much better
version of PHP. Forcing people to upgrade from 7.0 to 7.3, when it
will only be an incremental improvement is going to have much more
resistance from users.Because of that, I think we may feel pressure to slow down the change
in minor version numbers. I also just don't seem a problem in adding
functions in patch versions, so long as there is no BC break.One example : https://wiki.php.net/rfc/cyclic-replace can probably be
considered as a 'small self-contained' addition. Should I continue with the
RFC, respecting feature freeze and proposing it for 7.1, or should I just
ask the PR to be merged in 7.0 ?During the discussion of the RFC, several people voiced opposition to it.
Nikita Popov wrote:
I'm against this RFC. Not because I don't like the implementation or
similar, I simply don't consider this functionality to be sufficiently
important to warrant both the additional internal complexity it adds and
the complexity it adds to our user-facing API.So I think this does need an RFC to allow people to vote properly.
And yes, I think the preg_replace_callback_array addition probably
should have gone to a vote. I know some people have stated objections
about having too many RFCs - but I think that having a small hurdle to
adding stuff to core is not a bad thing. If nothing else, it forces
people to think and describe the changes clearly.
I don't see any negative to require RFC to be much more common. It promotes
more communication of an addition, and also helps provide documentation to
users about new features coming through as they can read the RFCs and see
what's approved, rejected, in limbo, etc.
cheers
Dan--
I know I'm new to this list, and its my first response, but I feel like
more transparency is a good thing for the users of PHP.
Cheers!
Ryan
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 difference there.
--
Stas Malyshev
smalyshev@gmail.com
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 difference there.
We see progresses with linux distributions, thanks our release process RFC.
Yes significant changes have to be seen once users migrate to these
versions. Ignoring this fact is dangerous, especially if it used to take
decisions about adding features to patch releases (arguments why already
mentioned).
--
Stas Malyshev
smalyshev@gmail.com
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 difference there.
The problem is that all the stats we have cover versions that predate the current release process. We've actually only had two "minor releases" under the new definition, 5.5 and 5.6; and the next release is a major, so will be different again.
If we have a smooth series of 7.x releases, we may see a very different pattern of adoption in, say, 5 years time. Unfortunately, we can't wait until then to decide on change policy, because the policy is required to get that adoption.
So ultimately, we have to make some informed guesses based on feedback, logic, and experience outside the project, about the impact of different kinds of process.
Regards,
Rowan Collins
[IMSoP]
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 anymore.
Having RFC is not related to change being self-contained, but rather
with if the change is obvious or needs more thorough discussion.
Usually the latter would also not be small, but not in every case. On
the other hand, the change may be needing thorough discussion, but when
the discussion has been done, the code change itself may be tiny and
self-contained. So it's not the same.
One example : https://wiki.php.net/rfc/cyclic-replace can probably be
considered as a 'small self-contained' addition. Should I continue
with the RFC, respecting feature freeze and proposing it for 7.1, or
should I just ask the PR to be merged in 7.0 ? If it is accepted by a
vote, can it still go to 7.0 ? It is really not clear to me.
This RFC seems to request a change in functionality of existing
function, which already does something (albeit not very useful thing).
This doesn't look like self-contained change to me.
--
Stas Malyshev
smalyshev@gmail.com
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.
--
Stas Malyshev
smalyshev@gmail.com