Re: Re: Bug 67072 resolution for 5.4/5.5

On Mon, Jun 23, 2014 at 11:42 AM, Julien Pauli <jpauli@php.net> wrote: > On Mon, Jun 23, 2014 at 11:19 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > > > > > > > > On Mon, Jun 23, 2014 at 11:16 AM, Matteo Beccati <php@beccati.com> > wrote: > >> > >> Hi Julien, > >> > >> On 23/06/2014 09:54, Julien Pauli wrote: > >> > I'm also ok for the 5.6 statements : > >> > - Disalow O: for classes with custom serializer > >> > - Unlock newInstanceArgWithoutConstructor() for internal classes > >> > > >> > Note that unlocking newInstanceArgWithoutConstructor() for internal > >> > classes may require lot of work. > >> > Remi already tried to patch some extensions for them to work AFAIR. > >> > >> With 5.6.0 being RC1 already, would someone have time and be willing to > >> commit doing all the work required without delaying the stable release? > >> I'm not entirely sure, but I certainly hope I'm wrong. > >> > > > > What do you mean? > > I can promise that the 5.6 RMs (Julien and Me) will make sure that we > have > > this sorted out for 5.6 before we have the final release if that is what > you > > are asking for. > > Sure. We can delay. We may delay. > If the quality of the project is involved, we will delay. > > 5.4 has been delayed, with 8 RCs before final, because of unresolvable > bug at this time. > However, for 5.6, we are already late on the schedule. Last RC of 5.4 > was taggued in February , our 1st RC for 5.6 has been taggued in June. > > If we go for checking all the internal classes shipped in the > distribution, then we should start the task ASAP. > We cant delay too much, and I think it is reasonable to have a release > during the summer. > > Julien > I'm not proposing to wait with the 5.6 final release until we fixed every internal class so it is safe to instantiate them without calling their constructors(as we discussed before that could even turn out impossible). What I meant that I can promise that we will have a solution for 5.6, which provides a feasible migration path for apps/libs currently depending on the unserialize O: hack to mock/thaw objects. -- Ferenc Kovács @Tyr43l - http://tyrael.hu