Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: <internals@lists.php.net>
Date: Sat, 21 Mar 2015 16:52:28 +0100
Message-ID: <000001d063ef$08af3ca0$1a0db5e0$@php.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01D063F7.6A74DD20"
Thread-Index: AdBj62f968l/cPHOShK7Fj4pq7qB7Q==
Content-Language: fr
Subject: Proposal to delay 7.0 timeline
From: francois@php.net (=?iso-8859-1?Q?Fran=E7ois_Laupretre?=)

------=_NextPart_000_0001_01D063F7.6A74DD20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

One month ago, I sent a message (https://marc.info/?l=3Dphp-internals
<https://marc.info/?l=3Dphp-internals&m=3D142449701107797> =
&m=3D142449701107797)
explaining in details why I thought we should take more time to gather
features for 7.0. Zeev replied that it was absolutely impossible, and =
that
the timeline had to be respected.

=20

Now, after more calls from many of you to delay it, and as Zeev himself
seemed to consider it as more acceptable, I am proposing again to delay =
7.0
feature freeze to May, 15 (2 month delay, date where vote is starting). =
I
won=92t repeat all the arguments of my previous posts but, to summarize, =
it
would allow to include important features, making it a =91real=92 major =
version.
Releasing a major version is not just a question of BC break, we also =
need
to think about what we put forward. So, we need features. We already =
have
STH, but we can do more (I personally have at least 4 RFCs I didn=92t =
have
time for, including scalar pseudo-methods, which can be an important
feature).

=20

@Anthony, don=92t get me wrong, it is absolutely not a way to keep =
competing
about STH. Your RFC is accepted, that=92s fine, the debate is over. If =
we
decide for an additional delay, I may propose something about STH, but =
it
will be a follow-up to your RFC, proposing additions, not an alternative =
STH
system.

=20

So, Zeev asked in a previous mail how we could decide to delay the =
timeline,
as it would theoretically require an RFC, which would take all the time.
Good question. But, as I have a feeling that everyone except Zeev was =
quite
flexible on the question, maybe we can have an agreement without =
organizing
a formal vote.

=20

Just a proposal, give thoughts.

=20

Regards

=20

Fran=E7ois

=20


------=_NextPart_000_0001_01D063F7.6A74DD20--