We have to deal with: * New entries in master for the next stable release * New entries in master that are backported to release branches * New entries in release branches that are not in master * Reverts in any of those scenarios
Also, in real life sometimes the changelog entry goes in a different commit that cannot be squashed because the original commit that forgot it is already pushed. Sometimes the changelog entry has a typo or something to fix and it is edited afterwards. Also, in the previous months of a major release there's typically *a lot* of cherry-picking. So much that in the Rails 3 days Rails Contributors started to count dup'ed entries as one. This is so changing, that I think we should just accept that the changelogs should be per release branch. I think that goes in the line of what Jeremy and Jon suggest. In 3-1-stable you have nothing related to 3.0, 2.3... anything but 3.1.x. In master you have nothing related to 3.1 and past releases. If a bug fix is applied to master and 3-1-stable you get an entry for both branches. The purpose of changelogs is not to have a summarized git log of the entire history of the module, it is a tool to be able to summarize what's new *per release*. So per release or per release branch seems to be a natural fit. I believe this is easier if it is maintained by hand, and I'd suggest that pull requests should not create changelog entries, core team would be responsible for creating an entry at our discretion, as happened in the past. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
