Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85575
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55199AE8.4090100@gmail.com>
References: <CAH-PCH74+2-S2ySME1X5QW5rA9Jb5=1T+hJ3t1sxHiaTO31RJA@mail.gmail.com>
	<55193060.5000804@php.net>
	<CAH-PCH6Q7FA536v8qABLSC9C2C0ufXOo2e0eWcB2QfJcLv+gSQ@mail.gmail.com>
	<CAMUwpuRYMxX9paP0y0-DHAdX4=TX7qeO8wS7Q_9QsU+A3x-rPw@mail.gmail.com>
	<55199AE8.4090100@gmail.com>
Date: Tue, 31 Mar 2015 03:31:58 +0200
Message-ID: <CAEZPtU6G1xfEeAu0UfRN5kWr_4erpRZ4-Nz_1RtRBYMyHWh3Pw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Julien Pauli <jpauli@php.net>, Ferenc Kovacs <tyra3l@gmail.com>, Michael Wallner <mike@php.net>, 
	PHP Internals <internals@lists.php.net>, Stanislav Malyshev <stas@php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Mar 30, 2015 at 8:50 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi!
>
>>     I tend to agree that it would be easier for all parties if we stop
>>     adding stuff in micro versions, as it is easier to remember and
>
> I don't think it is a good idea. Imagine you are a PHP developer working
> on a project, and you noticed there's some small functionality missing
> that would improve things a lot for you - like parameter to some
> function or returning some value that is missing. You could easily
> contribute it, but if it can't go in minor version there's no point for
> you to even bother. Because even if your org is super-up-to-date, they
> run 5.6, most realistically - 5.5, and if it's like the majority - it'd
> be 5.4 and worse. You could hope to convince your bosses and your ops to
> go to 5.6 and keep it reasonably updated within 5.6, but if the only
> addition you can make is 7.1, it's the lost cause - by the time your org
> could go to 7.1 your project will be long done (or at least long
> designed to work without this new feature) and you may be already
> working in another company. Yes, we have releases (almost) each year,
> but adoption of them is much slower, and with all BC breaks in 7.0 it
> would probably be even slower when going from 5 to 7, so this means
> doing small improvements to PHP is essentially of no practical value for
> PHP developer since there's no chance this improvement can be used in
> the lifetime of a typical project.
> I do not think it would be good for PHP.
>
>> As everything can be considered as beeing a BC break for at least
>> someone on Earth, I admit it is hard to understand the meaning of "small
>> self-contained additions in a micro version" :-p
>
> I do not think we should consider adding functions/options "BC break",
> not by any sane definition of it. Of course, nothing prevents somebody
> from using insane definitions, but it's of no concern to us.

The problem is always a definition question, a very subjective question.

I do not really buy the "I am stuck with x.y" as one has the same
problem already. And he has barely a 2 years window to add them.

About 7, yes, that's our only next release. We rejected any 5.7, so we
have to live with it.

Now, about the BC breaks, I do not see that much BC breaks for modern
apps and even WP or D7 work quite well. Let focus on that instead of
starting to using 5.6 as a solution of our frustration not being able
to move to 7, that would be terrible to have new features every patch
release. Let do not do that.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org