Support for Batch Preambles

[bephinix]

Problem and Use Case

The changelog keeps track of changes you made to your project and should help end-users and developers to understand which new features or breaking changes were introduced.
Changie combines different descriptions of changes together which will result in an overview for specific releases (tags).
Nevertheless it is sometimes a good idea, to describe your release/version in a few sentences so it is easier for other people to get an overview what the purpose of a release is without reading all specific changes.

Example:

## v1.2.3 (2021-04-05)

This release bundles a lot of new logging handler endpoints and an internal rework of the underlying log handling,
so it is recommended to check if another handler might able to increase the performance of your app.
[and a few sentences more]

### Added
- ...

### Fixed
- ...

Suggestion

One should be able to add an optional snippet/header if a new batch is created from unreleased fragments.
This might be implemented by providing a command line option which accepts a path to a file.
An interactive prompt is also a valuable option for short preambles.

Example Snippet:

This release bundles a lot of new logging handler endpoints and an internal rework of the underlying log handling,
so it is recommended to check if another handler might able to increase the performance of your app.
[and a few sentences more]

Changie CMD:

changie batch 1.2.3 --preamble path/to/file.md

[bephinix]

@miniscruff Thanks for creating this language-independent tool for basic changelog management! It will declare some (unreliable) bash scripts obsolete. 😉

[miniscruff]

Hi, @bephinix thanks for the feedback. The workflow I imagined was using changie batch 1.2.3 then simply editing the new file it created yourself before running changie merge. I could consider adding an optional parameter but I felt like editing it after batching would be a fair workflow. Open to further discussions though.

[bephinix]

@miniscruff Editing the created file is indeed a fair workflow if you interact with changie manually.
For a CI/CD workflow which handles the whole release process, a command line flag might be easier to use than injecting the text block afterwards (e.g. with sed).

[miniscruff]

Although Changie works in some regards perfectly well without any human interactions I would say it is still a human-driven CLI and is not meant to be automated entirely like that.

However, I think it is reasonable to use such a feature as a means of splitting ownership. That is Changie is used by developers to release the product, but each change and of course the release date can and in some cases should be under management or leadership. Therefore, a possible workflow could be:

1. N developers work on N features each with a change file approved by a lead
2. As a release is approaching the lead writes a header file to be included with the next release
3. This is done through the normal PR process and is reviewed by other leads and developers
4. Come release time, the resulting command could be changie batch v1.0.1 --header header.txt or through a config option of something like versionHeaderPath: header.txt of course this could be markdown, restructured, or whatever your team wants.
5. This would be optional and thus continue if the file was missing or empty, a possible flag could be "requireVersionHeader: true/false" which would exit 1 if the file was missing.

Note that since I generally create pull requests for the batch and merge commands, it would still be possible for a lead to interject and include a header. However, the requirement that a lead MUST review the PR instead of it automatically being merged sounds like a bad idea. That is, I like to say "leadership MAY review and approve changie pull requests" rather than "leadership MUST review and approve" since I think it's logical that if you reviewed and approved each PR leading up to the release you shouldn't also have to review the mostly automated Changie updates.

I used header here to match the header file that already exists when merging but it might make more sense to use a different term, but I feel they are basically the same thing for two different places.

[bephinix]

@miniscruff This will definitely solve the issue! 👍 My main reason for using a tool like Changie is that I only want to provide the ingredients for my changelog but this changelog itself can be generated automatically. As you already said, if all PRs are reviewed correctly, the generation itself can be done without any interaction as all work is already done.