Hi!
I see that there were significant changes committed to JSON extension in
5.3 and 5.4 recently. These changes modify json_encode behavior, break
tests (pass001.1_64bit.phpt does not work anymore for me), are not
clearly documented and have no NEWS/UPGRADING entries describing what
exactly changed, had no RFC, use new function with name inconsistent
with all existing functions with the same semantics
(json_last_error_msg) and IMO do not belong in stable branches,
especially not done this way.
I intend to release 5.4.5 RC1 next week, and I want this matter to be
cleared up before that, because I can not release it in this state. So
we have two options here:
- Revert everything to 5.4.4 state and deal with it in 5.5 or maybe in
5.4.6 if it'd be ready. - Have it cleaned up ASAP and brought to a state where there are no
test failures and there's a clear description of what the changes were
in NEWS and UPGRADING.
I think option 2 is better, but if it can not happen by EOD Tuesday
(July 3) I intend to go with option 1. Nikita, please advise how you
prefer to proceed with this.
Johannes, do you want me to revert it in 5.3 branch too in case we have
to go with option 1?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I see that there were significant changes committed to JSON extension in
5.3 and 5.4 recently. These changes modify json_encode behavior, break
tests (pass001.1_64bit.phpt does not work anymore for me), are not
clearly documented and have no NEWS/UPGRADING entries describing what
exactly changed, had no RFC, use new function with name inconsistent
with all existing functions with the same semantics
(json_last_error_msg) and IMO do not belong in stable branches,
especially not done this way.I intend to release 5.4.5 RC1 next week, and I want this matter to be
cleared up before that, because I can not release it in this state. So
we have two options here:
- Revert everything to 5.4.4 state and deal with it in 5.5 or maybe in
5.4.6 if it'd be ready.- Have it cleaned up ASAP and brought to a state where there are no
test failures and there's a clear description of what the changes were
in NEWS and UPGRADING.I think option 2 is better, but if it can not happen by EOD Tuesday
(July 3) I intend to go with option 1. Nikita, please advise how you
prefer to proceed with this.Johannes, do you want me to revert it in 5.3 branch too in case we have
to go with option 1?
Hi Stas!
If you are okay with the changes in principle, I will fix the
remaining issues asap. If you think that the changes are too intrusive
for release branches, I'll gladly revert them for 5.3/5.4. I didn't
quite expect that there will be so many changes.
Apart from that one test, does anything else fail for you? I didn't
notice that one test because I'm running on 32bit.
Regarding documentation, should these changes be documented in detail
in NEWS? Or does it suffice to update the documentation? For
UPGRADING, which one should it go in? Just 5.3?
Nikita
If you are okay with the changes in principle, I will fix the
remaining issues asap. If you think that the changes are too intrusive
for release branches, I'll gladly revert them for 5.3/5.4. I didn't
quite expect that there will be so many changes.
I think in 5.3 we don't need changes. 5.3 is a stable stable stable
branch. Fixing bugs, ok, changing behavior: No go.
I haven't looked at it in detail, though.
johannes
On Sun, Jul 1, 2012 at 1:27 AM, Johannes Schlüter
johannes@schlueters.de wrote:
I think in 5.3 we don't need changes. 5.3 is a stable stable stable
branch. Fixing bugs, ok, changing behavior: No go.
Agreed.
One question: When I revert the changes to 5.3 should I also revert
the original change that was released in 5.3.14?
(http://git.php.net/?p=php-src.git;a=commit;h=3f3ad30c50c32327e723046bcc6649d05dd9236a)
The change was reverted on 5.4, but was missed on 5.3.
It is present only in that one release and is currently not documented
in any way.
Nikita
Johannes Schlüter <johannes <at> schlueters.de> writes:
I think in 5.3 we don't need changes. 5.3 is a stable stable stable
branch. Fixing bugs, ok, changing behavior: No go.I haven't looked at it in detail, though.
johannes
Indeed, 5.3 seems very stable. We ran many tests.
Regards,
Max Benson
http://www.plothost.com
Hi!
If you are okay with the changes in principle, I will fix the
remaining issues asap. If you think that the changes are too intrusive
for release branches, I'll gladly revert them for 5.3/5.4. I didn't
quite expect that there will be so many changes.
I think changes with adding new functions, etc. are too intrusive for
5.3/5.4. If you have any fixes that can be done without it, please
describe them and let's see if they fit stable versions. Otherwise,
let's go back to stable. In any case, the tests should be fixed too.
Apart from that one test, does anything else fail for you? I didn't
notice that one test because I'm running on 32bit.
That's the only test that failed for me in 5.4.
Regarding documentation, should these changes be documented in detail
in NEWS? Or does it suffice to update the documentation? For
UPGRADING, which one should it go in? Just 5.3?
It would be best to have short description in UPGRADING and full
description in the docs. NEWS should have short mention of it. But since
we're talking about moving all substantial changes to 5.5, that's where
it should be.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
If you are okay with the changes in principle, I will fix the
remaining issues asap. If you think that the changes are too intrusive
for release branches, I'll gladly revert them for 5.3/5.4. I didn't
quite expect that there will be so many changes.I think changes with adding new functions, etc. are too intrusive for
5.3/5.4. If you have any fixes that can be done without it, please
describe them and let's see if they fit stable versions. Otherwise,
let's go back to stable. In any case, the tests should be fixed too.
I don't think one can do anything on 5.3/5.4 without altering the
behavior too drastically. I reverted all changes I did there:
https://github.com/php/php-src/commit/250393f92523fffe643df06a1de2101fd50a327e
(5.3)
https://github.com/php/php-src/commit/b7903f9778a57fda71867f9661505f635d602067
(5.4)
I did not revert
http://git.php.net/?p=php-src.git;a=commit;h=3f3ad30c50c32327e723046bcc6649d05dd9236a
though. Leaving the decision on that one to Johannes :)
Nikita
Le 01/07/2012 00:59, Stas Malyshev a écrit :
Hi!
I see that there were significant changes committed to JSON extension in
5.3 and 5.4 recently.
Another minor documentation problem:
Last pecl version on json extension, released in 2006 was 1.2.1
Version included in 5.3 and 5.4 still reports as 1.2.1.
If extension change (bugfix or new features) shouldn't version change ?
If nobody want to take care of bundled extension version, shouldn't it
be removed ?
Regards,
Remi.