Repository navigation
Support for Batch Preambles #92
Description
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
Activity
bephinix commentedon Apr 5, 2021
@miniscruff Thanks for creating this language-independent tool for basic changelog management! It will declare some (unreliable) bash scripts obsolete. 😉
miniscruff commentedon Apr 5, 2021
Hi, @bephinix thanks for the feedback. The workflow I imagined was using
changie batch 1.2.3then simply editing the new file it created yourself before runningchangie 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 commentedon Apr 5, 2021
@miniscruff Editing the created file is indeed a fair workflow if you interact with
changiemanually.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 commentedon Apr 5, 2021
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:
changie batch v1.0.1 --header header.txtor through a config option of something likeversionHeaderPath: header.txtof course this could be markdown, restructured, or whatever your team wants.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 commentedon Apr 5, 2021
@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.