Hi,
 
This seems to necessitate one commit per feature/fix/etc, which is not always desireable. Especially for larger features, where one may want to split them further
 and work in smaller incremental commits.
As we work with Github in practice, it looks like our logical unit of work is not a commit, but a pull request. I would say such convention would very much
 make sense to implement for PR descriptions. I just don’t know if there’s a way to generate a changelog from those.
 
Alex
 
Von: Michael C. Jaeger [mailto:mcj@xxxxxx]
Gesendet: Donnerstag, 8. Dezember 2016 17:50
An: sw360-dev@xxxxxxxxxxx
Cc: sw360dev@xxxxxxxxxxx
Betreff: conventional changelog
 
 
 
Hi,
how about improving the commit style of messages using conventional changelog?
 
fix(licenseinfo) correcting bug with GPL-2.0 missing
 
feat(portlets) improving attachment list with datatable
 
docs(docker) adding information to install compose separatedly
 
style(vulnerabilities) changing indendation
 
refactor(scheduling) moving out specific scheduling functionality
 
test(projects) adding test for access by moderators
 
Then, if we have sufficient coverage, we could go over and auto generate the release notes …