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?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
- internal src compatibility
oh, thats the same as internal API compatibility, then I'm not sure
what "src compatibility should be kept if possible, while breakages
are allowed" is referring to, as both internals API/ABI, and userland
API is mentioned already in the rfc for the minor version.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
"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
Pierre Joye 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.
This is where the modular/bundled discussion comes in? Anything that is bundled
has to be nailed down, but creating a new extension, or SAPI that is shipped
separately is a different matter? Even creating a variation of a currently
bundled extension such as a major update to a linked library need not impinge on
the core and should not need every other extension to be updated!
I'm still of the opinion that there should be more unbundling, then areas like
the current debate on MySQL support can be ring fenced to that set of
extensions. They are not a core requirement therefore can be left out. ANY
changes which bridge the gap between extensions should perhaps be restricted to
X.0.0 level anyway. Certainly any bug in an extension which requires the core to
be modified to be fixed would indicate a coding problem that needs addressing?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
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.This is where the modular/bundled discussion comes in?
No, it is not, absolutely not. Please do not hijack again this thread
with this discussion, it is totally off topic.
SAPIs are what makes possible to get PHP works in a shell, apache, fastcgi, etc.
Thanks for your understanding,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
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.This is where the modular/bundled discussion comes in?
No, it is not, absolutely not. Please do not hijack again this thread
with this discussion, it is totally off topic.SAPIs are what makes possible to get PHP works in a shell, apache, fastcgi, etc.
Thanks for your understanding,
Sorry I don't understand why you say this is not the same discussion.
Personally I only use an Apache SAPI but I can quite see that other people want
a bundle with different SAPI's. These are different targets which a single fully
bundled distribution is just excessive. The current pressure is to get even more
things included in an already bloated core bundle, when a sensible debate on a
more targeted distribution model ... such as like the Linux distributions
already break things down to ... makes perfect sense to me.
Exactly the same debate is going on with Eclipse distributions, to simplify
targeted bundles, and make it easier for people to tailor a bundle to their own
requirements ... individual extension/plugins develop with their own version
numbers without impinging on the core engine. Self contained modules such as
individual SAPI's can be develop independently as required, and should not need
to have a debate on whether they should be bundled or not if the distribution
model allows their publication as an installation option?
Returning to the rfc process ... what still seems to be missing is a way of
handling these parallel developments rather than just simply 'throwing them out
for pecl to handle'?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Sorry I don't understand why you say this is not the same discussion.
Personally I only use an Apache SAPI
They can't be distributed like pecl's extension. That's why. off topic, take #2.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org