Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85650
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.172 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <32D4890E-E746-4DB5-8147-889EA9CB4454@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>
	<5519B3E3.1070102@gmail.com>
	<5519C9E0.6010001@gmail.com>
	<551A8B42.6080603@gmail.com>
	<551AFF0B.7020903@gmail.com>
	<32D4890E-E746-4DB5-8147-889EA9CB4454@gmail.com>
Date: Wed, 1 Apr 2015 19:49:18 +0100
Message-ID: <CAEKnhAHV++BdKDQZFoRT8Ubjy=u21AqvEeaXXyVmhk8Hcn0nng@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114093ae2f93ab0512ae2cf7
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: bukka@php.net (Jakub Zelenka)

--001a114093ae2f93ab0512ae2cf7
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 31, 2015 at 9:44 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev <
> smalyshev@gmail.com> wrote:
> >> This is a straw man as far as the points I made are concerned. I'm
> >> talking about the risk of switching from 5.5 to 5.6, which is pretty
> >low.
> >
> >Switching to 5.6 would be useless since what is being propose it to ban
> >any enhancements up to 7.1.
>
> Proposed by whom? The only mentions of 7.1 I've spotted have been from
> you, which is why I called it a straw man.
>
> So, rather than arguing round in circles, here's what I would propose:
>
> - Up until the first release candidate of x.y.0, small features can be
> added to both the most recent live branch and the new branch being prepared
> for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and
> 7.1-pre).
> - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug
> fixes only. Thus 5.5.x should not be receiving features.
> - As an exception to the above, when releasing x.0.0, the previous branch
> may continue receiving small features, until it reaches the end of its
> "active support" phase. In other words, keep backporting things to 5.6.x
> after 7.0.0 is released, since adoption of the latter is likely to be slow.
> By the time 7.1.0 comes around, active support for 5.6 will have ended
> anyway, unless we make some other exception to the normal process.
>
> This is very much a compromise between the SemVer ideal of a patch
> release, and the practical implications of a yearly release cycle. The aim
> is to make it obvious to users what they'll get in return for upgrading,
> and to smoothly transition a branch from "cutting edge" to "stable with bug
> fixes", then to "security only" and "end of life".
>
> What do people think?
>

+1

--001a114093ae2f93ab0512ae2cf7--