On Fri, 2014-01-31 at 13:51 +0100, Pierre Joye wrote:
> On Fri, Jan 31, 2014 at 1:36 PM, Johannes Schlüter
> <[email protected]> wrote:
> > On Mon, 2014-01-27 at 21:15 +0100, Anatol Belski wrote:
> >> https://wiki.php.net/rfc/size_t_and_int64
> >
> > It is my understanding that part of the reason for the release workflow
> > RFC was that if patches miss the mark they don't have to wait for long
> > till the next release comes.
> >
> > In this case here we have 5.6.0alpaha1 out. Adding a major API change
> > touching each and every file can't be added to 5.6 anymore.
> >
> >
> > Also the release process RFC says
> >
> > x.y.z to x.y+1.z
> > [...]
> > ABI and API can be broken (internals), src compatibility
> > should
> > be kept if possible, while breakages are allowed
> >
> > This rule contains many things that "can" and "should" and thus is
> > open
> > to interprettation.
>
> No, it is open to common sense and give us the opportunity to break
> ABI if we like to in x.y+1. We did that in 5.4 and 5.5.
So what is the purpose of the rule? If a "normal" RFC vote can do
whatever it likes why have that rule? As you are the author I'm happy to
learn your interpretation.
> > In my interpretation this rule is meant to allow
> > small changes, affecting only few extensions and where it would be
> > stupid to defer the.
>
> To defer the ...?
... the change.
> At least you did not loose your sense of humor.
Yes, humor indeed helps if the one who creates the rules is also the one
who tries to bend it the most.
johannes