On Wed, Feb 9, 2011 at 7:40 PM, Ryan Davis <ryand-r...@zenspider.com> wrote: > We're going to start using a convention I've been using in perforce and on my > jobs for years now. Commit messages will have lines prefixed to convey what > type of change they are: > > ! major change / enhancement > + minor change / enhancement > - bug fix > not worth mentioning in the release > > No wrapping lines in your commit message. If you have 2 changes they go on > separate lines. >
The problem I see with this approach are changes that span across multiple commits and touch different files. If we use the same description for each commit, it looses the a way for doing quick log and see when things are introduced and what. I personally prefer updating History.txt myself and include: == (Not Released) * Bugfixes: * Etc. you get the idea. Either by automated tools or not, parsing before a release still remains something manual, so why not make it more easy for contributors to work directly into that file? In case of pull requests, after a merge I update the History to reflect the changes taking part of the pull request description and given the proper attribution. If we enforce this, needs to be documented in a contribution document so pull requests commits can follow these rules and is less work for us. Just my point of view. Cheers, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
