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.jo...@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
