Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85622
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain bof.de designates 80.242.145.70 as permitted sender)
MIME-Version: 1.0
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 06:58:36 +0200
Message-ID: <CAJ26g5TO2JoEsu4PEeVa6HncZZVr996Fak5e6eo4MUQt-YSUBQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Stas Malyshev <smalyshev@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11479df06242e00512a29175
Subject: Re: [PHP-DEV] What's our official stance on small self-contained
 additions in a micro version
From: php@bof.de (Patrick Schaaf)

--001a11479df06242e00512a29175
Content-Type: text/plain; charset=UTF-8

Am 31.03.2015 22:45 schrieb "Rowan Collins" <rowan.collins@gmail.com>:
>
> - 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?

That sounds very reasonable, and would suit me fine :)

One issue that I think speaks for such an approach, is giving
new-small-features better exposure outside of developer circles. If
features only ever go into the-next-tree, they won't be seen and tried out
in the field until after that is committed as a new-stable release. The
feature also probably can't be added to the php.net documentation until
that release happens (right). Lots less eyes seeing it, finding problems
with it that might be rectified before next-becomes-stable.

I think there's a three layer hierarchy of adoption at play here, which
also can explain the low adoption figures of newest-stable. At the top, you
have next-stable, which will be visible almost exclusively to contributors,
and won't get any real world production exposure at all. Then you have the
current stable, which is used by shops (like mine...) that care about
building their own binaries, and that have a rather homogenous inhouse
codebase that can evolve to use new major and minor features in production.
And then there's the vast field which runs on distribution builds, which
seems to sit on the oldest supported stable version in existence until it's
faded out, and which doesn't care about new features at all.

Do I make sense? :)

best regards
  Patrick

--001a11479df06242e00512a29175--