Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55740
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Date: Fri, 7 Oct 2011 22:28:17 +0200
Message-ID: <CAH-PCH7ifnqWsCcK6PXfp2BodnxaazqZjqpmdVDRcDgnodwLHg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: little tweeking on the release process RFC
From: tyra3l@gmail.com (Ferenc Kovacs)

Hi

I just read through the releaseprocess RFC(
https://wiki.php.net/rfc/releaseprocess ) again, and I think that the
part where we explain the Release Process and the BC could be
clarified a little bit.
(We still haven't agreed on the how many concurrent versions should we
support, how long would be a version supported, doing LTS, etc. but
thats another topic)

"No feature addition after final x.y.0 release (or x.0.0). Self
contained features or new SAPIs could be carefully considered on a
case by case basis."
I would re-phrase the No feature addition to changing existing
behavior, as it now seems a little bit contradictional.

"Backward compatibility must be respected with the same major
releases, for example from 5.2 to 5.6. Binary compatibility can be
broken between two features releases, f.e. between 5.3 and 5.4:"
it is explained below this line, but maybe it would worth explicitly
stating which BC are we referring to, as BC could also mean ABI/Binary
compatibility which would again contradict the second sentence.

for micro version, I would extend the bugfix part, for example the
is_a fix can be called a bugfix, but large amount of code was
depending on the buggy behavior hence the change affected a large
amount of core out there, and the "right" behavior was achievable
through other methods(using additional class_exists/interface_exists),
so maybe we could mention some kind of rule for this.

"Backward compatibility must be kept (internals and userland)" and
"ABI/API compatibility must be kept (internals)" seems overlapping
again.

I think we should formalize the different kind of BCs, the following
were mentioned in the RFC:
- moving extensions from core to pecl (maybe also define adding new
extensions, or moving from pecl to core)
- internal src compatibility
- internal ABI compatibility
- internal API compatibility
- userland API compatibility

maybe it would be also a good thing to mention that the preferred way
to break userland API compatibility is to first mark the
feature/behavior as deprecated (documentation and/or E_DEPRECATED) and
only remove it after that (which could only happen with a minor or
major version by the RFC) plus the possible migration path should be
also documented if possible.

what do you think?

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu