releasenote-builder: should have execution mode to fail if release version (by pom) is not matching to issues labels

[Roman Ivanov]

Correct:
https://cloud.drone.io/checkstyle/checkstyle/12329/4/2
in pom 10.3.3-SNAPSHOT
in releasenotes

Checkstyle 10.3.3 - https://checkstyle.org/releasenotes.html#Release_10.3.3
Bug fixes:
  Translate messages to Russian
  RequireThisCheck not able to handle try-with-resource
  Sarif support is not extended onto the Ant task defined.
  InvalidJavadocPosition: false positive for the generic constructor without access modifier
Notes:
 ......

Correct:
in pom 10.4-SNAPSHOT
in releasenotes

Checkstyle 10.4 - https://checkstyle.org/releasenotes.html#Release_10.4
New:
  RequireThisCheck not able to handle try-with-resource
Bug fixes:
  Translate messages to Russian
  Sarif support is not extended onto the Ant task defined.
  InvalidJavadocPosition: false positive for the generic constructor without access modifier
Notes:
 ......

Incorrect:
https://cloud.drone.io/checkstyle/checkstyle/12325/4/2
in pom 10.3.3-SNAPSHOT
in releasenotes

Checkstyle 10.3.3 - https://checkstyle.org/releasenotes.html#Release_10.3.3
New:
  RequireThisCheck not able to handle try-with-resource
Bug fixes:
  Translate messages to Russian
  Sarif support is not extended onto the Ant task defined.
  InvalidJavadocPosition: false positive for the generic constructor without access modifier
Notes:
 ......

Rules is simple:
if pom version is 3 digits and in issue label generate releasenotes where is "new" or "breaking compatibility" - ERROR
if pom version is 2 digits and in issue label generate releasenotes where are no "new" or "breaking compatibility" - ERROR

We need new option validateVersion
https://github.com/checkstyle/contribution/tree/master/releasenotes-builder#command-line-usage
this validation should happen at the most end to let all results be printed and done.
This mode should be activated only in drone CI to fail in master branch build and notify maintainers that version type in pom and by labels is mismatching.
Maintainer will make decision to bump version in pom or change labels.

It is not rare case that labels are not placed properly and we need to change labels. It is better for us to make CI just point to mismatch and let people decide what is correct.

Side Effect: when new Check is introduced in PR we put @since in it and we validate it to be a version that we have in pom. After merge CI might fail as pom has 3 digits but new Check means version should be 2 digits. Maintainer should do version bump AND update new Check to have reference new version.

[Roman Ivanov]

historical context:

All below is NOT for action, just for information:

https://github.com/checkstyle/checkstyle/wiki/How-to-make-a-release

Next version. Review all changes and if where is no new Checks or new options in Checks or any new functionality that might require updated in some Checkstyle plugins and integrations - please bump only 3rd digit of release number

We thought to automate it ....., it suppose to be shell script that look at release notes and make decision and do version change.
Attention: we usually comeback to minor version increase rigth after release (because https://github.com/checkstyle/contribution/edit/master/checkstyle-tester/pom.xml#L15 need to know next version, but may be it is time to drop this dependecy and get such version by script, see checkstyle/checkstyle#11724 (comment)).
Rule is simple:
if there is breaking changes or new section - minor version bump.
if there is only bugs and notes - patch version bump.
Historically we expect that each new version is minor version bump as we release not that frequently and usually something new is merged each month.
Here is example of recent path version bump - https://checkstyle.org/releasenotes.html#Release_9.2.1

[Roman Ivanov]

Example of usage:

1. now we have 10.3.4-SNAPSHOT in pom.
2. we merge some PR that is for issue that is marked as "breaking compatibility"
3. build in master fail (if we finish #648)
4. maintianer review failure in CI and confirm that we need to change version to 10.4-SNAPSHOT
5. maintainer run action(R: Bump version/Update Milestone bump-version-and-update-milestone.yml) to update version in pom and in github milestone
6. ready to merge new PR ..... release will be considered to be done in some time in future, may in few weeks.

[Roman Ivanov]

Fix is merged