Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85663
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain birkholz.biz does not designate 144.76.185.252 as permitted sender)
Message-ID: <551C48AC.3090908@birkholz.biz>
Date: Wed, 01 Apr 2015 21:36:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Stanislav Malyshev <smalyshev@gmail.com>, internals@lists.php.net
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com> <551BC7CF.3080309@birkholz.biz> <551C44C7.6060108@gmail.com>
In-Reply-To: <551C44C7.6060108@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: dennis@birkholz.biz (Dennis Birkholz)

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