-----Original Message----- From: Matthew Weier O'Phinney [mailto:weierophin...@php.net] Sent: 23 November 2010 14:18 To: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Release Process
On 2010-11-23, Derick Rethans <der...@php.net> 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 | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc +1 PHP is big/grown-up/widely-used enough now that "shipping is a feature" It's gone beyond just being a beginners tool for knocking out basic web pages. Enterprise (who-ever that is :-) now uses PHP and as such will want PHP to have some degree of uniformity with release cycles and feature addition/removal so that they can easily factor it in to their own deployment/upgrade plans etc. While they dislike change (tongue in cheek), they dislike the unknown more. Transparency also helps people get on board from both a developer perspective and user one too. It gives little people the warm and fuzzy feeling because they can at least understand how everything works/decisions are made even if they aren't involved in them, and if they did want to get involved, they can see what they have to do. just my 2 cents. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
