Rainer Jung wrote: > On 08.04.2012 15:28, Jeff Trawick wrote: >> Perhaps it is just my nature to disagree with everybody when there is >> some contentious discussion. Or just possibly it is my nature to try >> to pull apart what was discussed (or yelled), throw away the most >> extreme aspects, and see if there is anything to agree on. (Even in >> the absence of past success at doing so :( ) >> >> Procedure: >> >> Below is what I observe and practice for changes made to the stable >> branches, and I believe this is clearly the widespread, accepted >> pattern. Furthermore I believe it is simple enough that it can be >> followed without demands for documentation, even though such >> documentation would be fine. >> >> Commit to trunk. >> Commit to 1.9.x, 1.8.x, 1.7.x, etc. down to the actively maintained >> stable branch. In cases where the actively maintained stable branch >> has recently changed, it is up to the committer to decide whether to >> commit to the previous actively maintained stable branch. (There is >> at least limited value in having the project decide what the patch for >> some branch is even if there are no clear plans to release it.) >> >> Commit messages for the branches always explicitly reference the trunk >> revision, not relying on mergeinfo, which does not show up in normal >> views of revision history. >> >> Modifications expected to remain only in trunk, at least for some >> time, should be accompanied by a CHANGES entry in trunk, if >> appropriate. CHANGES entries are appropriate for user-visible changes >> to a previously released feature or for user-visible feature >> additions. >> >> When committing to previously released branches, the CHANGES entry >> should be part of the commit, whether or not it was part of the trunk >> commit. (A CHANGES entry is commonly omitted from the trunk commit if >> a backport will be performed almost immediately.) >> >> Do you disagree with the procedure and/or my attempt to describe the >> "normal" way this is handled? > > No, I agree and I think it is more useful to include the CHANGES entry in the > backport commit than to split it in a > second commit. At least that's what I tried to do in the past influenced by > following the list and commit messages. > Sometimes the CHANGES entry either is forgotten during the backport commit or > postponed by a differing personal > preference and is then added soon as a separate commit which I think is less > useful but still acceptable.
+1 Regards Rüdiger
