Re: svn: /php/php-src/branches/PHP_5_4/ext/fileinfo/ fileinfo.c tests/bug61173.phpt

On 03/07/2012 10:22 AM, Stas Malyshev wrote:

Hi!

I think what Chris is asking is to have NEWS entries in the branch where a commit is done, no mater if the fix was already reported in a previous branch NEWS file.

It'd mean instead of easy merge on release we'd have to have hard and time-consuming cleanup of old NEWS - I'd have to go through NEWS and for each entry go to 5.3 NEWS and check if it's there too and if it's there remove it. Or we'd just have it twice in both 5.3 and 5.4 sections?

Ideally from the users/readers point of view, each branch that has a fix would have a related NEWS entry. With git this discussion might be moot so we might want to drop this thread. However my general standpoint is: 1. we should commit a comment to each branch's NEWS file when code is committed to that branch. 2. the previous branch's NEWS files would not be merged into the N+1 branch at N+1 release. 3. the RC release fixes would stay under their RC section headers. This would mean trivially more developer effort at commit time but would: 1. show more accurately what is fixed in any code bundle. 2. require almost no manual cleanup at release time (except for grammar etc).

We need to figure it out btw as if we carry NEWS with patches in git that would mean patches will never cleanly apply between branches (as NEWS files are always different). We need to have a better mechanism for this.

If NEWS was automatically generated at push time or prior to release, then discussion is moot. Yes, some one-off manual tidy up might be needed at release time.

BTW, why we don't put the same in the trunk NEWS then?

Because of the current manual merge of the previous branch's NEWS at the time a new branch is released. E.g. 5.4.0 NEWS included the 5.3.10 NEWS. Chris -- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/