Re: [RFC] Release Process
| From: | Matthew Weier O'Phinney | Date: | Tue, 23 Nov 2010 14:17:49 +0000 |
| Subject: | Re: [RFC] Release Process | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-50448@lists.php.net to get a copy of this message | ||
On 2010-11-23, Derick Rethans <derick@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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc