# What's our official stance on small self-contained additions in a micro version

- Thread: https://externals.io/message/85545
- Original archive: https://news-web.php.net/php.internals/85545
- Started by Ferenc Kovacs on 2015-03-30T10:04:33+00:00
- Messages: 59
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/85545.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #85545 — Ferenc Kovacs — 2015-03-30T10:04:33+00:00

URL: https://externals.io/message/85545#85545

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

---

## #85549 — Michael Wallner — 2015-03-30T11:15:44+00:00

URL: https://externals.io/message/85545#85549 · In reply to: #85545

> 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

---

## #85550 — Pierre Joye — 2015-03-30T11:36:08+00:00

URL: https://externals.io/message/85545#85550 · In reply to: #85549

>
> 
> > […]
times
> > […]
just
> > […]
consensus
> > […]
>
> 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")`?

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

---

## #85553 — Ferenc Kovacs — 2015-03-30T13:10:43+00:00

URL: https://externals.io/message/85545#85553 · In reply to: #85549

> 
> > […]
> times
> > […]
> consensus
> > […]
>
> 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,

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

---

## #85554 — Julien Pauli — 2015-03-30T13:28:42+00:00

URL: https://externals.io/message/85545#85554 · In reply to: #85553

>
>
> 
>
> > […]
>
> 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).
>

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

---

## #85561 — Levi Morrison — 2015-03-30T16:14:03+00:00

URL: https://externals.io/message/85545#85561 · In reply to: #85545

> 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.

---

## #85565 — Stanislav Malyshev — 2015-03-30T18:50:16+00:00

URL: https://externals.io/message/85545#85565 · In reply to: #85554

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

---

## #85566 — Rowan Collins — 2015-03-30T20:36:51+00:00

URL: https://externals.io/message/85545#85566 · In reply to: #85565

> Hi!
>
> > […]
> 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.

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).


> > […]
> 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]

---

## #85567 — Stanislav Malyshev — 2015-03-30T20:52:12+00:00

URL: https://externals.io/message/85545#85567 · In reply to: #85545

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

---

## #85568 — Ferenc Kovacs — 2015-03-30T21:08:23+00:00

URL: https://externals.io/message/85545#85568 · In reply to: #85567

On Mon, Mar 30, 2015 at 10:52 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > […]
>
> 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'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

---

## #85570 — Stanislav Malyshev — 2015-03-30T22:10:40+00:00

URL: https://externals.io/message/85545#85570 · In reply to: #85566

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

---

## #85571 — Stanislav Malyshev — 2015-03-30T22:13:14+00:00

URL: https://externals.io/message/85545#85571 · In reply to: #85568

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

---

## #85572 — Christoph Becker — 2015-03-30T23:05:51+00:00

URL: https://externals.io/message/85545#85572 · In reply to: #85570

Stanislav Malyshev wrote:

> > […]
> 
> 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

---

## #85574 — Stanislav Malyshev — 2015-03-31T00:00:25+00:00

URL: https://externals.io/message/85545#85574 · In reply to: #85572

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

---

## #85575 — Pierre Joye — 2015-03-31T01:31:58+00:00

URL: https://externals.io/message/85545#85575 · In reply to: #85565

> Hi!
>
> > […]
>
> 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.
>
> > […]
>
> 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 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

---

## #85581 — Rowan Collins — 2015-03-31T11:55:46+00:00

URL: https://externals.io/message/85545#85581 · In reply to: #85570

Stanislav Malyshev wrote on 30/03/2015 23:10:
> Hi!
>
> > […]
> 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).


> > […]
> 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.


> > […]
> 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.


> > […]
> 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.


> > […]
> 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.


> > […]
> 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.

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.


> > […]
> 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]

---

## #85601 — Stanislav Malyshev — 2015-03-31T19:57:18+00:00

URL: https://externals.io/message/85545#85601 · In reply to: #85575

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

---

## #85604 — Stanislav Malyshev — 2015-03-31T20:09:47+00:00

URL: https://externals.io/message/85545#85604 · In reply to: #85581

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

---

## #85607 — Rowan Collins — 2015-03-31T20:44:28+00:00

URL: https://externals.io/message/85545#85607 · In reply to: #85604

> > […]
>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]

---

## #85608 — Rowan Collins — 2015-03-31T21:05:17+00:00

URL: https://externals.io/message/85545#85608 · In reply to: #85604

Sorry for the double reply, but I wanted to pick up on one particular point.


>Hi!
>
> > […]
>maintain a
> > […]
>backported
> > […]
>"5.5.9+dfsg-1ubuntu4.7",
> > […]
>patches,
> > […]
>
>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]

---

## #85617 — Pierre Joye — 2015-03-31T23:47:47+00:00

URL: https://externals.io/message/85545#85617 · In reply to: #85601

hi,

ps: please keep the "xyz wrote", makes harder to read your replies without it


> Hi!
>
> > […]
>
> 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.


> > […]
>
> 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.


> > […]
>
> 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.

> > […]
>
> You 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.

> > […]
>
> 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

---

## #85622 — Patrick Schaaf — 2015-04-01T04:58:36+00:00

URL: https://externals.io/message/85545#85622 · In reply to: #85607

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

---

## #85623 — Stanislav Malyshev — 2015-04-01T05:52:47+00:00

URL: https://externals.io/message/85545#85623 · In reply to: #85622

Hi!

> > […]
> 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).
> > […]
> bug fixes only. Thus 5.5.x should not be receiving features.
> > […]
> 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

---

## #85624 — Stanislav Malyshev — 2015-04-01T06:28:01+00:00

URL: https://externals.io/message/85545#85624 · In reply to: #85617

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

---

## #85630 — Lester Caine — 2015-04-01T08:24:25+00:00

URL: https://externals.io/message/85545#85630 · In reply to: #85624

> 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

---

Next page: https://externals.io/message/85545.md?page=2