Re: release process

At 13:10 02/03/2002, derick@php.net wrote:

However, it seems hard job for RM to check all commit & merge. Since RM must maintain release branch at least few monthes after 4.2.0 is released. It seems current way is working well. We may need some guideline for how we maintain release brach, though. Erm, don't you recall me bitching if somebody MFHed to the branch without discussing it? =) I think it's quite doable, and I'm sure it can be done. And those guidelines are already posted to PHP QA yesterday.

I don't want to make a big fuss out of this, but remember that what we had with 4.2.0 is something we should try to avoid in the future, rather than set as our goal. In a perfect situation (which is quite practical), the delta between versions wouldn't be as big as it is between the 4.1.0/4.2.0 versions. So there will be no point in maintaining the 4.2.0 branch for too long anyway. The reason we had 4.1.x miniversions coming out was only because we branched 4.1.0 much too often. If it was branched on time (much later), it would have included most of the changes in 4.2.0, and it would have been possible to avoid the branch-based miniversions altogether. Our QA process should be quicker, we should be less tolerant to new features going into release branches, etc. If we do that - there's no reason why a release branch shouldn't be alive for only about 10 days, and then reused only if there's some major bug (should not happen if our QA is setup right) or a security issue found. As for the matter itself - I agree with Jani/Derick completely that only the RM should be responsible for merging in patches (even though ack'ing the patch and verifying the diff is just as good as doing it himself, if not better). Zeev