Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55745
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH-PCH7ifnqWsCcK6PXfp2BodnxaazqZjqpmdVDRcDgnodwLHg@mail.gmail.com>
References: <CAH-PCH7ifnqWsCcK6PXfp2BodnxaazqZjqpmdVDRcDgnodwLHg@mail.gmail.com>
Date: Sat, 8 Oct 2011 08:27:56 +0200
Message-ID: <CAEZPtU5HzURdjnwY0ncreHVQJj6EtNJG5mf4WEYTP70bpP+6UQ@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] little tweeking on the release process RFC
From: pierre.php@gmail.com (Pierre Joye)

On Fri, Oct 7, 2011 at 10:28 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:

> "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.

I don't see how it is contradictory. SAPIs are self contained and
can't harm another SAPI, that's why we added this clause.

> "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.

While talking about ABI, it is about internals only, there is no ABI
for userland codes.

> for micro version, I would extend the bugfix part, for example the
> is_a fix can be called a bugfix,

It was a bug fix which was causing a BC break and should not have been
applied in the 1st place.

> "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)

That should no't happen in patch releases anymore.

> - internal src compatibility
> - internal ABI compatibility
> - internal API compatibility
> - userland API compatibility

We added src compatibility for clarity on request. ABI is about
internals only, API is about userland and internals.

> 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.

Not if possible, a must. That's the goal of the migration guide and
its version in the PHP manual. The doc team has done a great job so
far, let keep it updated, that's the way to go.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org