Release notes automation

Release notes creation will be half-automated process, admin have to group events by 3 categories manually : "Breaking backward compatibility", "New", "Bug fixes", "Notes" . We need a tool that generate UL-LI content of sections tag at example.

1. We always grab changes to Release notes from GIT commit messages, as we reflect actual changes, all other approach is error prone

2. format: "^.* . Issue #\d*$" WE NEED to treat ID of PR as Issue, as for github it is the same - they share number set. We have to expect commit without reference to issue number - minor updates ( that does not make sense to create issue to).

3. issue have to exists on github (Do we need to check for open state ???? Some changes are done with reference to already closed issues as minor update but author still want to let others know context, It will be a build failure as PR number is know only after PR is sent.!!!!!)

4. if issue is valid we ignore commit message and use issue tittle (as issue state what is wrong and commit message is tending to have what was fixed and how). Release notes need "what was wrong". We can always change message of issue to make release notes looks good. We can change PRs title and description at any time so we are OK to treat PR as Issue. So contributor can do PR, got a failure , update a commit and push in the same PR.

What to do with commit that reference few issues? - rare case we could use commit message and change it manually if required (complete automation does make sense for now).

We do not analyse/use PR description at all, we skip commit message if issue number is reference (as we will use issue title).

we could enforce commit message format by UT on travis, we will validate commit by running "mvn verify" or all Uts. if commit is created on local that will force user to make message as we require. Validation could be done by special UT that use JGit to analyse repo.

5. We need an option to ignore certain user from release notes created, I do that with my commits, as I usually help other to finish their changes and rarely do fixes myself (I hope that will change one day when we have more admins with RW access to repo).

6)user need to specify tag from which to start ReleaseNotes creation, here is how I do that now - https://github.com/checkstyle/checkstyle/wiki/How-to-make-a-release#before-starting

we have PR from:

1. from Issue - the simplest case, we just demand issue number to be present in all commits.

2. from online changes (without clone) - 2.1) done by admins - I do it very often, especially at README.md or any other text file (we could have ignore option for admins) 2.2) done by others - usually typo changes or smth minor, it will NOT be a problem as such changes only fail a build and Admins still have right to merge changes even build is failed at certain UT. Tool will ignore commits that commited by admins (trust/super users).

3. from PRs (without issue, as contribution to non existing problem)example - 3.1) for enhancements and minor refactoring - THAT will be a problem . 3.2) for problems in design - that will be ok , as it will force to pay attention problem and write UTs too, and state a reason of update. 3.3) for functional changes - UTs changes required so it is not a just throwing code at us , it do need UTs to keep 100% and even more extension of UTs even coverage is 100%. Any functional changes have to be UTed.

Examples from other projects:

Issue at the end of message: https://github.com/spring-projects/spring-framework/commit/36ed4df59df03082b510841e55511d02424b7e56

issue at the beginning: https://github.com/hibernate/hibernate-orm/commits/master https://github.com/adangel/pmd/commits/master