Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85633
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: <551BC7CF.3080309@birkholz.biz>
Date: Wed, 01 Apr 2015 12:26:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>
In-Reply-To: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.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)

Hello,

Am 30.03.2015 um 12:04 schrieb Ferenc Kovacs:
> I know that our official release process allows that, but there are some
> reasonable arguments against doing that and this topic was brought up
> multiple times related to specific fixes.
> I have two open PRs like that:
> https://github.com/php/php-src/pull/1204
> https://github.com/php/php-src/pull/969
> and of course there are a bunch of similar ones from other people, and
> there are cases when somebody simply pushes a change like that, other times
> somebody points out that it should require an RFC(
> https://wiki.php.net/rfc/json_preserve_fractional_part for example), but
> most of the times we simply don't know what to do, and eventually we just
> let the PR/patch to rot and die.
> I would like to know if we can come up with a rule which can have consensus
> behind it, and maybe formalize it as an extension to our current
> releaseprocess rfc.

in my opinion all feature changes should go in the next X.Y version and
should require an RFC.
The reason is that "small self-contained changes" that get pulled in
without a discussion on internals and an RFC can easily lead to bad
design decisions in the long run.

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.

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.
But for the distro package maintainers and the users it would be a lot
easier if e.g. the debian version could just be the latest patch version
and not a mix of several versions after their package freeze.

So, please let the x.y.z versions contain only additional (security)
fixes and stick to the RFC process, thanks.

Greets
Dennis