|
Hello, I am going to ask all commiters to follow simple but
effective patterns when commiting in order to ease the extraction of important
events from the commit logs. A trac plugin is under development that will parse
log lines and do different presentations of these logs automatically : for users,
for developers, for packagers, for translators,.. Could you please comment on the following proposals,
add yours, … I’d like to get us settled on this by the end
of the week. Thank you, Jerome 1/ commit tags 1a/ seem necessary '* (bugfix)' when a bug was corrected '* (buildfix)' when a build problem was corrected '* (doc)' when documentation/specs/READMEs are added to the
project '* (feature)' when a new feature is added '* (refactoring)' when the code was refactored '* (void)' uninteresting commit (a test commit for example) ‘* (i18n)’ When something deals with localization 1b/ other ideas '* (build)' when the build system is modified '* (packaging)' a commit that deals with packaging '* (init)' for the first installement of a project '* (fix)' for fixing commit errors '* (ticket #123)' when a non-bug ticket was resolved '* (cleaning)' when the code was reformated/beautified without
any other modification or obsolete files are deleted '* (refactoring)' when the code was refactored '* (silent)' do not echo this commit log into the changelog 2/ commit styles 2a/ with parenthesis * (bugfix) this is my bugfix * (feature) this is my feature 2b/ without parenthesis * bugfix : this is my bugfix * feature : this is my feature |
_______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
