Changelog Scripts

[onerandomusername]

Is there an existing issue for this?

• [X] I have searched the existing issues and there is no existing issue.

What is the feature?

Changelogs should be handled by some scripts for this project.

Preferably, all output should be controlled by a jinja2 template, so its easy to modify the program output in the future. Any needed configuration should be from a toml or yaml configuration file, and not as a file constant.

There's two seperate scripts and one workflow here.

• the compiler, which compiles the fragments into the changelog file
• a generator, which assists with a user creating a fragment for their contribution
• a very simple check workflow, which just checks that a user has added a fragment to the folder,

The compiler script is the most complex by design, whereas the generator script can be as simple or as complex as desired.

Naming scheme

All fragment files should be named like 123.feature.md 123 being the pull request number, and the second part being the kind of change. If multiple changes were made in a pr, 123.feature.2.md should be supported. The number is mostly irrelevant, but should be used for ordering the changes.

Compiler Script

Configuration should be able to set all of the different categories and their positioning. The version to build can be gathered from either modmail.__version__ or from [tool.poetry.version] in pyproject.toml The changelog file itself should be able to be controlled with a jinja2 script. In addition, there should be a configurable option for what regex or string in the existing changelog file to inject the new underneath.

Generator

The generator is the user-facing script which helps generates a new fragment file. If desired, feel free to use click to help make the UI. The end goal here to easily make a fragment file. Aside from being able to supply everything in the command with flags, this should also prompt the user for input if it was not provided.

Other thoughts

After thinking about it, a pre-commit script might be cool for checking files in the changes directory are validly named. This is not necessary, but might be a fun addition

Would you like to implement this yourself?

No, someone else can implement it

[Shivansh-007]

How about something like <datetime>.pr-<github pr number>.<type>.md. This would help us keep the news files in the directory ordered by the date of the merge and keep the order more easy to navigate. In case a PR adds to feature (may never happen), we can add a MD5 hash of the text to the end of the file name.

Example: 2017-05-04-12-24-06.pr-848.bug.QwErTy.md

[onerandomusername]

How about something like <datetime>.pr-<github pr number>.<type>.md. This would help us keep the news files in the directory ordered by the date of the merge and keep the order more easy to navigate. In case a PR adds to feature (may never happen), we can add a MD5 hash of the text to the end of the file name.

Example: 2017-05-04-12-24-06.pr-848.bug.QwErTy.md

Having a a date of the merge is not possible, since the frag must be made before the pr is merged. It can also be gotten from the github api or commit history.

[Shivansh-007]

I was thinking of changing the name (date section) of the script during the merge...

[onerandomusername]

I was thinking of changing the name (date section) of the script during the merge...

The information needed is accessible from github's api so this isn't necessary.