Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71462
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADNQb0WRn+sGOP=M0VtzwJ=2CHEmW7k_W0ZdNesd620_2hX7sg@mail.gmail.com>
References: <fa05c43bc2fff5420759e05dee19c99f.squirrel@webmail.klapt.com>
	<CAF+90c8mDBqe+E=cWxpD-U48Ho0QV3iHiwS9pOSEbUn_uZTVnQ@mail.gmail.com>
	<CA+9eiLvhRqFAunM8GCpqE5ja2jXKCzFMKdtF0NkBT11nu=36MQ@mail.gmail.com>
	<CAEZPtU7-mBoXcsvXQvD42uG58KKKLY3TJL=aV5uqcGEFhE3PKQ@mail.gmail.com>
	<CAEZPtU7vJDEyZAeCPR3j7_4+HL-4iCMUd3+Xa94xzg7xe1Z91Q@mail.gmail.com>
	<52E0F55F.4040802@lsces.co.uk>
	<CAF+90c8E6cKh7bt5KDdhxZso=sheNMGyLgdjA+9zckqoOL8jMg@mail.gmail.com>
	<2490044a0e2cba88044cf5da9b1b6647.squirrel@webmail.klapt.com>
	<CADNQb0U+Re=KY18g970Uk31V8SEK5D8S1xU464bFScm7P_gU3g@mail.gmail.com>
	<CAEZPtU5+qLxm+p2ppx+8AkoscuHZLgHGeaFivhRyMM4zfPPcFw@mail.gmail.com>
	<CADNQb0WRn+sGOP=M0VtzwJ=2CHEmW7k_W0ZdNesd620_2hX7sg@mail.gmail.com>
Date: Thu, 23 Jan 2014 20:55:30 +0100
Message-ID: <CAEZPtU6FiRqPAcjNMZu8JU8FOdd0KtYih9A374yJ=_dXohy=cQ@mail.gmail.com>
To: Hannes Magnusson <hannes.magnusson@gmail.com>
Cc: Lester Caine <lester@lsces.co.uk>, PHP internals <internals@lists.php.net>, 
	Nikita Popov <nikita.ppv@gmail.com>, Anatol Belski <ab@php.net>
Content-Type: multipart/alternative; boundary=001a11c3f8aaad937004f0a89f2c
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: pierre.php@gmail.com (Pierre Joye)

--001a11c3f8aaad937004f0a89f2c
Content-Type: text/plain; charset=UTF-8

Hi,

On Jan 23, 2014 8:35 PM, "Hannes Magnusson" <hannes.magnusson@gmail.com>
wrote:
>
> On Thu, Jan 23, 2014 at 11:16 AM, Pierre Joye <pierre.php@gmail.com>
wrote:
> > On Thu, Jan 23, 2014 at 7:38 PM, Hannes Magnusson
> > <hannes.magnusson@gmail.com> wrote:
> >> On Thu, Jan 23, 2014 at 9:52 AM, Anatol Belski <ab@php.net> wrote:
> >>
> >>>> If this patch is included in PHP 5.6 I think it is very likely that
many
> >>>> extensions will not be updated or take a long while in updating.
It's one
> >>>> thing to add two or three new ifdefs to support a new PHP release and
> >>>> something entirely else to change virtually all types in your code
and
> >>>> verify that it is still safe with the new sizes.
> >>> I think it depends on how active an extension is supported and
developed.
> >>> For instance on PECL are still some extensions not even been ported to
> >>> PHP5. From the todays experience, a port to the current patch might
take
> >>> from 3 hours to 3 days, depending on complexity. Say 3 days vs 5
months
> >>> until final, together with the porting docs and tools, most of the
really
> >>> active and being in demand extensions will be so far or users will
tear
> >>> the devs apart :)
> >>>
> >>
> >>
> >> If zpp/error_docref/*printf compatibility is not kept it will take a
> >> long time to update pecl extensions, and risk epic failure in the
> >> future when continuing the work on the extensions
> >>
> >> zpp (COMPAT ? "zyx" : "xyz", &foo, &bar, &baz) will in 1year turn into
> >> zpp (COMPAT ? "zyx|xz" : "xyz|z", &foo, &bar, &baz, &meh) and work
> >> just fine.. until you hit the perfect storm
> >>
> >>
> >> Its easy to migrate php-src exts since they don't have to care about
> >> compatibility with multiple php versions, but needing to support 5.3,
> >> 5.4, 5.5, 5.6, 5.7, 6.0 in a pecl extension will be nightmare
> >>
> >> Also, keep in mind most developers priority is not to work on
> >> supporting unreleased versions of PHP, but to keep maintaining the ext
> >> and adding features - so even though the guesstimate 5months "until
> >> final" is true, the extensions won't be updated until 5months _after_
> >> 5.6.0 is out.
> >
> > We have ported many extensions (all actively used and maintained) for
> > 5.5.0 before it was released. Some bugs appeared when used with 5.5
> > and was discovered after final, but that's expected and nothing we can
> > do about it but test, test and test :)
>
>
> Can I see 3 examples of pecl extensions you have ported, out of those
> many and actively used, that need to support multiple PHP versions?
> It would help to clearly visualize the full workload.
>
> Also, are you planning on doing this migration for all pecl
> extensions? If not, then my argument still stands.

Check Anatol or my commits or PRs. And yes we keep contribute to many
extensions in core and pecl, and yes we keep report bugs, and yes we test
these exts too.

> Waiiit.. You are talking about 5.5? Not 5.6 with this patch?
> Yeah, supporting 5.5 wasn't a major deal. It didn't change zpp or
> *printf() arguments.

5.5 was a piece of cake but for APC (same with 5.4).

And again, zpp is one of the open questions.

Printf changes are necessary for 64bit integer. There is no big problem to
deal with that.
Cheers,
Pierre

--001a11c3f8aaad937004f0a89f2c--