On 2010-11-23, Felipe Pena <felipe...@gmail.com> wrote: > --001636eef06580573f0495ae312f > Content-Type: text/plain; charset=UTF-8 > > Hi, > > With the recent chaos in the way we begin and ended releases, we would > like to propose a clean way to deal with releases and related decisions: [1] > > PHP releases have always been done spontaneously, in a somehow chaotic > way. Individual(s) decided when a release will happen and what could > or could fit in. Release managers role are unclear and the way to > nominate them is not clearly defined either. > > The goals of this RFC aim to solve these issues while giving to us, > our users and 3rd parties (distributions, contributors, etc.) more > visibility and the ability to actually have a roadmap, or plan > developments. This RFC aims to define: > > * a clear release cycle, periodic > * a transparent decision process for the feature additions, via > the RFCs and a transparent but anonymous vote > * which changes can be done during a release lifetime (BC breaks, > bugs fixes, security fixes, etc.) > * a transparent way to choose release managers for a given release > * a better usage of bugs.php.net to track each change, addition, > bug fixes (security incl.) or other various tasks related to a release > * reduce time between bugs fix releases > * reduce the time to get new features in a release > * suppress BC breaks in bugs fix releases > * feature(s) preview release
thanks for preparing this, as matthew and andi pointed out, more structure is a good idea. I still think even with all the things in the RFC in place, we are still very flexible. Having planned releases and clear processes how to reduce BCs and add transparency was always a good thing in the projects I worked on. So I'm definatly in favor of this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
