Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50515 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16612 invoked from network); 25 Nov 2010 10:47:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Nov 2010 10:47:30 -0000 X-Host-Fingerprint: 217.114.211.68 unknown Date: Thu, 25 Nov 2010 05:47:29 -0500 Received: from [217.114.211.68] ([217.114.211.68:15508] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 52/16-20008-0CE3EEC4 for ; Thu, 25 Nov 2010 05:47:29 -0500 To: internals@lists.php.net References: User-Agent: slrn/0.9.9p1 (SunOS) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-Posted-By: 217.114.211.68 Subject: Re: [RFC] Release Process From: dsp@php.net (David Soria Parra) On 2010-11-23, Felipe Pena 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.