Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50448 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12371 invoked from network); 23 Nov 2010 14:17:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Nov 2010 14:17:50 -0000 X-Host-Fingerprint: 65.19.76.48 unknown Date: Tue, 23 Nov 2010 09:17:49 -0500 Received: from [65.19.76.48] ([65.19.76.48:20401] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/B0-08358-D0DCBEC4 for ; Tue, 23 Nov 2010 09:17:49 -0500 Message-ID: <58.B0.08358.D0DCBEC4@pb1.pair.com> To: internals@lists.php.net References: User-Agent: slrn/pre1.0.0-16 (Linux) X-Posted-By: 65.19.76.48 Subject: Re: [PHP-DEV] [RFC] Release Process From: weierophinney@php.net (Matthew Weier O'Phinney) On 2010-11-23, Derick Rethans wrote: > On Tue, 23 Nov 2010, Ferenc Kovacs wrote: > > > All the rest you write in the RFC is basically already as we do it. > > > > yeah, maybe, but they aren't written down, accepted and well-known rules, so > > you can forgot/misunderstand/bend them. :/ > > And I don't think that is a bad thing. It's good to be able to be > flexible. A good artist is capable of great flexibility within the constraints of their medium. In the case of software releases, you can still have greate flexibility even with an existing release process. In many ways, having the process defined helps bring about creative solutions -- "if I want to get this in time for the release, what solution will work best?" I used to love the ad hoc nature of "we'll release when it's ready." However, having done quite a number of scheduled releases, I've found that: * Predictability motivates developers. "Release is in 3 months? Okay, let's get rolling on this!" * Knowing when the next release is coming also means that developers are more comfortable if they're unable to make the deadline. "I can't do it by this release, but I should have no trouble making the next." * Less stressful for release managers. If the code isn't ready by the deadline, it's not merged to the branch, plain and simple. The status quo works great for those whom it serves. For everyone else, it stinks. There's no transparency, which leads to disenfranchisement. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc