Support for Batch Preambles about changie HOT 5 CLOSED

@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.

from changie.

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

from changie.

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.

from changie.

@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).

from changie.

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.

from changie.