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? a. Did I misrepresent the project norms? Please follow up to this thread. b. Do you believe it should be done differently, irregardless of project norms? Please propose something different in a new thread.
