> > > > We also have no plan about what will or will not be 5.4. This looks > > familiar, this is exactly how we begun 5.3 and it tooks literally > > years to be released. There is also actually no agreement to begin > > with 5.4 now. > > Yes, but instead of defining "what is PHP 5.4", why not just go with > what we have? Everything that's not in thre is for PHP-next-next again. >
backward compatibility™ we had a few nice things in the PHP6 branch, which got merged into the trunk, before choosing the version number for the trunk. it's okay, but we agreed on that if that gets into the trunk, that it doesn't mean, that it will be shipped automatically with the next release. you can read again the fuss about the scalar type hinting: after a release, we start to think trunk as a development branch, where everything can get in: At 18:04 22/05/2010, Pierre Joye wrote: > hi Zeev, > > It seems that there was a bit of discussions on IRC about committing > Ilia's implementation. However it is trunk, and trunk is a development > tree. That means its purpose is to develop new PHP features. But it > does not meant that these features will make it in the next releases > or if they will remain as they are now. but when we start to roll out a release, laziness/eagerness kicks in, and we start rambling about status quo (if it's in the trunk, then its ready to go). On Sat, May 22, 2010 at 11:10 AM, Zeev Suraski <z...@zend.com> wrote: > Maybe I view trunk in a different way than others, but I think committing > it turns it into some sort of 'status quo', and now we'd need a good reason > to change it. > And after all those discussion about the past and current scalar type hints, here they are: they are planned to be released, without consensus, and the current implementation doesn't even the same, that we talked our ass off about. :/ > > 5.4 should be hold off until we solved the listed issues and the > > release management RFC gets discussed and hopefully approved. > > Why do you need a release management RFC? We've made releases for more > than a decade just fine. > yeah, but the current situation is a little bit different(we have code in the trunk which was intended for 6.0, where bc isn't a problem at all), than the previous ones. and I think we can't say that there are room for improvements about the current "lackoff" release policies. hell, we don't even agree on things like what is the status of the code in trunk(can we commit without consensus, or do we decide about it before the release), or what are the rules for the versioning schema(which version is allowed to break what). :/ > > Stalling every time doesn't get us anywhere. IMO we should just go with > it. I am absolutely against stalling again! > > I am too, but I think that we should carefully cherrypick, what to release with 5.4 from the current trunk. Tyrael
