PHP 5.6 end of active support

7 years ago by Christoph M. Becker — view source

unread

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] http://php.net/supported-versions.php

--
Christoph M. Becker

7 years ago by Kalle Sommer Nielsen — view source

unread

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc

[1] http://php.net/supported-versions.php

--
Christoph M. Becker

7 years ago by Dennis Clarke — view source

unread

Hi

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc

This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports and push through this
or the 5.6.x version will be dropped with no valid replacement that
works in a strict environment. Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.

Dennis Clarke

7 years ago by Davey Shafik — view source

unread

On Wed, Dec 14, 2016 at 7:15 AM, Dennis Clarke dclarke@blastwave.org
wrote:

Hi

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc

This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports and push through this
or the 5.6.x version will be dropped with no valid replacement that
works in a strict environment. Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.

PHP 5.6 isn't EOL for a further two years, you should be fine.

Davey

7 years ago by Dennis Clarke — view source

unread

PHP 5.6 isn't EOL for a further two years, you should be fine.

Thank you so much. I can only guess this is posted on a "lifetime" page
somewhere on php.net but I didn't see it.

Dennis

7 years ago by Marco Pivetta — view source

unread

See https://secure.php.net/supported-versions.php

PHP 5.6 isn't EOL for a further two years, you should be fine.

Thank you so much. I can only guess this is posted on a "lifetime" page
somewhere on php.net but I didn't see it.

Dennis

7 years ago by Dennis Clarke — view source

unread

See https://secure.php.net/supported-versions.php

I see.

I guess the question has to be "why is the 5.6.x codebase only to
receive security fixes for a very brief while into 2017" ? Just
curious what the thinking is here.

Dennis

7 years ago by Nikita Popov — view source

unread

On Wed, Dec 14, 2016 at 9:39 PM, Dennis Clarke dclarke@blastwave.org
wrote:

See https://secure.php.net/supported-versions.php

I see.

I guess the question has to be "why is the 5.6.x codebase only to receive
security fixes for a very brief while into 2017" ? Just
curious what the thinking is here.

PHP 5.6 receives security fixes for the entirety of 2017 and 2018, not "a
very brief while into 2017".

7 years ago by Dennis Clarke — view source

unread

On Wed, Dec 14, 2016 at 9:39 PM, Dennis Clarke dclarke@blastwave.org
wrote:

See https://secure.php.net/supported-versions.php

I see.

I guess the question has to be "why is the 5.6.x codebase only to receive
security fixes for a very brief while into 2017" ? Just
curious what the thinking is here.

PHP 5.6 receives security fixes for the entirety of 2017 and 2018, not "a
very brief while into 2017".

Sorry ... I was looking at the 5.5 line there. The 5.6.x line seems to
be very reasonable and safe.

Dennis

7 years ago by Ryan Pallas — view source

unread

On Wed, Dec 14, 2016 at 1:39 PM, Dennis Clarke dclarke@blastwave.org
wrote:

See https://secure.php.net/supported-versions.php

I see.

I guess the question has to be "why is the 5.6.x codebase only to receive
security fixes for a very brief while into 2017" ? Just
curious what the thinking is here.

It goes to 2018, see the RFC [1] that extended it.

[1] https://wiki.php.net/rfc/php56timeline

Dennis

7 years ago by David Zuelke — view source

unread

Hi

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc

This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports

Yes, you do. PHP 7.0.0 was released a year ago.

and push through this
or the 5.6.x version will be dropped with no valid replacement that

5.6 will receive security fixes for another 24 months.

works in a strict environment. Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.

It appears to be, from looking at https://bugs.php.net/bug.php?id=67229, but that affects PHP 5 as well, not just 7.

David

7 years ago by Dennis Clarke — view source

unread

Hi

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

Yes, 5.6 was extended to compensate for 5->7 adoption afair from an rfc

This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports

Yes, you do. PHP 7.0.0 was released a year ago.

and push through this
or the 5.6.x version will be dropped with no valid replacement that

5.6 will receive security fixes for another 24 months.

works in a strict environment. Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.

It appears to be, from looking at https://bugs.php.net/bug.php?id=67229, but that affects PHP 5 as well, not just 7.

Actually looking at that bug we see the problem again. This is a
Solaris 10 system, which is a very strict POSIX system, but the
compiler being used is gcc and the option --std=gnu99 makes reference
to a "defacto standard" that exists no where. So this is exactly the
problem I see in many many places, code gets releases that compiles
with gcc on some systems but will not pass even a basic compile on a
strict system with a very tightly conforming compiler such as the
Oracle Studio 12.5 tool set. Some code is amazingly clean like libgmp
and we also have PHP 5.6.x which compiles with some extensions but the
7.x codebase won't compile. At all. Yet. Very close however.[1]

So I need to dig into this as I am sure whatever things I can uncover
and perhaps patch will be of benefit across all systems everywhere. I
think that is what ( now I am just being pedantic ) standards are all
about. Total portability.

Dennis

[1] discussion happened last month in "[PHP-DEV] C89 vs. C99" thread

7 years ago by Andrea Faulds — view source

unread

Hi,

Dennis Clarke wrote:

This is entirely too soon. At the present moment neither of the PHP 7.0
releases will compile clean on a strict POSIX environment. At all. The
version 5.6.x tree is perfectly stable and works out of the box without
an endless compile nightmare whereas 7.0.14 and 7.1.0 won't even
compile. I guess I need to file more bug reports and push through this
or the 5.6.x version will be dropped with no valid replacement that
works in a strict environment. Perhaps the gcc compiler is an absolute
requirement and if that is true then the code isn't acceptable to any
other compiler regardless if it is C99 compliant or otherwise.

GCC is not a requirement. At the very least, PHP compiles on clang and
MSVC, and I believe it works with some other compilers also.

--
Andrea Faulds
https://ajf.me/

7 years ago by Dennis Clarke — view source

unread

<snip> >> Perhaps the gcc compiler is an absolute >> requirement and if that is true then the code isn't acceptable to any >> other compiler regardless if it is C99 compliant or otherwise. > > GCC is not a requirement. At the very least, PHP compiles on clang and > MSVC, and I believe it works with some other compilers also. >

I have to test with a very strict POSIX system compliant to POSIX.1-2001
and Single UNIX Specification, Version 3 (SUSv3). There is also XNS4
sockets and XTI interfaces which really is XNS5 which is a superset
and LP64 clean derivative of XNS4. The XNS4 spec is 32-bit only and I
think nearly everything lately is targetted to 64-bit systems specs. Not
sure as I am sure there are a bucket of 32-bit embedded systems on the
market still with things like Motorola or Freescale system on a chip
embedded solutions for automobiles and mobile data access pads. Those
are almost always a custom 32-bit Linux kernel for touch screen apps and
other control solutions etc etc.

However within the strict confines of C99 there is the Oracle Developer
Studio which conforms to the ISO/IEC 9899:1999 and ISO/IEC 9899:1990. I
think that ISO/IEC 9899:2014 standards compliance is in progress. With
some feature test macros we can get access to extensions. From the very
long and pedantic man page :

  If the application is using interfaces and headers
  not  defined  by that standard, then in addition to defining
  the appropriate standard feature test macro,  it  must  also
  define  __EXTENSIONS__. Defining __EXTENSIONS__ provides the
  application with access to all interfaces and headers not in
  conflict  with  the specified standard. The application must
  define __EXTENSIONS__ either on the compile command line  or
  within the application source files.

So the POSIX.1-2001 standards compliance can be enforced with the simple
define -D_POSIX_C_SOURCE=200112L but going all the way up to SUSv3 will
require -D_XOPEN_SOURCE=600. This is getting a bit off topic but the
real idea here is that php 5.6.29 will compile perfectly in a 64-bit
strict environment with the allowance for extensions. There is no need
to resort to GCC which is not yet in full compliance. PHP 5.6.x then
runs its entire testsuite and the results are very positive. This can
not ( yet ) be done with PHP 7.x for any value x but I am certainly
going to try.

OKay .. so the long winded summary is that hoo ray PHP 5.6.x will be
around long enough for PHP 7.x to slowly become serious code clean and
it may compile within a very strict environment.

Dennis

7 years ago by Niklas Keller — view source

unread

2016-12-14 12:23 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] http://php.net/supported-versions.php

It has support until the end of the year, so I guess there will be one more
release with regular fixes in early January.

Regards, Niklas

7 years ago by Christoph M. Becker — view source

unread

2016-12-14 12:23 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] http://php.net/supported-versions.php

It has support until the end of the year, so I guess there will be one more
release with regular fixes in early January.

Indeed, that is what I'm asking for: will PHP 5.6.30 contain "normal"
bugfixes, or security fixes only?

I'm asking because it's not clear to me whether "normal" bugfixes now
should go to PHP-5.6+ or PHP-7.0+.

--
Christoph M. Becker

7 years ago by Ferenc Kovacs — view source

unread

2016-12-14 12:23 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] http://php.net/supported-versions.php

It has support until the end of the year, so I guess there will be one
more release with regular fixes in early January.

Regards, Niklas

yep, that's my plan, and the PHP-5.6 branch will be closed for regular
bugfixes after tagging 5.6.30RC1:
http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=fdff955c6b13c434aab40cb35cf002ab7c7eb146;hb=HEAD#l32
from that point on only RMs can push changes to the PHP-5.6 branch.
going into extended support also means that there won't be RCs as we don't
have regular bugfixes and we won't have a release each month, only when
there are security fixes ready to be released for 5.6

7 years ago by Alice Wonder — view source

unread

2016-12-14 12:23 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

Hi!

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] http://php.net/supported-versions.php

It has support until the end of the year, so I guess there will be one
more release with regular fixes in early January.

Regards, Niklas

yep, that's my plan, and the PHP-5.6 branch will be closed for regular
bugfixes after tagging 5.6.30RC1:
http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=fdff955c6b13c434aab40cb35cf002ab7c7eb146;hb=HEAD#l32
from that point on only RMs can push changes to the PHP-5.6 branch.
going into extended support also means that there won't be RCs as we don't
have regular bugfixes and we won't have a release each month, only when
there are security fixes ready to be released for 5.6

I want to say a huge thank you for doing this. When 5.6.0 was new I
moved all sites I am responsible for to it, and I have started porting
my other sites to 7.1 but haven't finished yet. This gives me a few
months to make sure everything really does work as intended.

5.6.x IMHO was a fantastic branch throughout and I thank all the devs
for it as I look forward to 7.1

7 years ago by Christoph M. Becker — view source

unread

2016-12-14 12:23 GMT+01:00 Christoph M. Becker cmbecker69@gmx.de:

The end of active support for PHP 5.6 is documented to be on December,
31th[1]. Does that mean that there'll be no further release with
"normal" bug fixes (but only security fixes)?

[1] http://php.net/supported-versions.php

It has support until the end of the year, so I guess there will be one
more release with regular fixes in early January.

yep, that's my plan, and the PHP-5.6 branch will be closed for regular
bugfixes after tagging 5.6.30RC1:
http://git.php.net/?p=karma.git;a=blob;f=hooks/pre-receive;h=fdff955c6b13c434aab40cb35cf002ab7c7eb146;hb=HEAD#l32
from that point on only RMs can push changes to the PHP-5.6 branch.
going into extended support also means that there won't be RCs as we don't
have regular bugfixes and we won't have a release each month, only when
there are security fixes ready to be released for 5.6

Thanks for the explanation, Ferenc! :-)

--
Christoph M. Becker