Tools: Start a release notes initializer script in python List excluded change subject keywords at the beginning of the python script, for frequent update convenience. That list could be moved to a file if eventually more convenient. Excluded subjects will likely be listed again but in their own section, for a human editor to ponder. Base the script on regex patterns matching. Summarize usage through a README and help for the options. Provide main usage examples in README. The '-c' (check) option takes much more runtime and is in beta. That option tries to exclude commits contained in previous release tags. It is yet to be proven, as it had some visible effect only once, so far. Generated notes list every change in revision range, in git log order. Deeming a subject as noteworthy remains a manual, post editing step. Issues follow their referring change subject rather than the reverse. The latter could be added eventually as another generated view or so. Redundant information is prevented as much as currently implemented. The script currently only lists change subjects and the related issues. Manual editing is expected then to add more, edit or remove information from the generated release_noter.md (markdown file). The latter file is not to be used as is for Gerrit but rather manually imported in parts. Black is used for automatic code formatting. Flake8 was tried but did the opposite of black, locally. It is therefore not used yet. Adding logic to group specific subjects in specific component sections is yet to be done. The script already does it for the submodule (core) plugins. The other large section currently is for all core changes and their issues. Splitting into more component sections, to do soon, will help handling the large generated release notes. JGit may be split too. Another upcoming backlogged item is to add links to the listed change commits nearby issues. Goal being, to be able to double-check the notes manually or at will. This script is more complex than [1] but was originally inspired by it. This assumes the current way of formatting Gerrit git commit messages, without expecting more headers or footers. Near-term plan is to consider refactoring release_noter's main parsing loop, based on [2]'s approach. [1] https://git.eclipse.org/r/c/tracecompass.incubator/org.eclipse.tracecompass.incubator/+/144581 [2] https://www.pydanny.com/why-doesnt-python-have-switch-case.html Bug: Issue 13483 Bug: Issue 13484 Feature: Issue 11123 Change-Id: Ifadc5e742f8a2a7bc0b1c2bc7e021c330c010ac2
diff --git a/tools/release_noter/Pipfile b/tools/release_noter/Pipfile new file mode 100644 index 0000000..32907e1 --- /dev/null +++ b/tools/release_noter/Pipfile
@@ -0,0 +1,12 @@ +[[source]] +name = "pypi" +url = "https://pypi.org/simple" +verify_ssl = true + +[dev-packages] +black = { version = "==20.8b1", markers = "python_version >= '3.8'" } + +[packages] + +[requires] +python_version = "3.8"