Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85657
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.172 as permitted sender)
Message-ID: <551C44C7.6060108@gmail.com>
Date: Wed, 01 Apr 2015 12:19:35 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Dennis Birkholz <dennis@birkholz.biz>, internals@lists.php.net
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com> <551BC7CF.3080309@birkholz.biz>
In-Reply-To: <551BC7CF.3080309@birkholz.biz>
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: smalyshev@gmail.com (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.

> 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.


> 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.

-- 
Stas Malyshev
smalyshev@gmail.com