I don’t release OSS software so this is a peanut gallery comment. But I don’t understand the preoccupation with changelog-driven anything. The changelog is the

I don’t release OSS software so this is a peanut gallery comment. But I don’t understand the preoccupation with changelog-driven anything. The changelog is the source of truth? The VCS log is a guaranteed sort of truth. Now having a single file that everyone else can read is convenient. But I don’t quite understand being so motivated to go through a lot of hoops (like automating the changelog, dealing with merge conflicts from multiple contributors when appending to one changelog file). What I would naively do if I wanted to automate the changelog: - Make a script that creates the Git (or whatever) tag and also appends everything new to the changelog via something like git-shortlog Using a GitHub workflow for that seems complicated (yaml and all). But if I wanted a curated changelog? I guess I would write it semi-manually: maybe some scripting around the git-log (for relevant pieces) and sprinkled in with either deletions of things that are too technical or nitty gritty + additions of things that the user might care about (but might be obvious from the log for the developers, i.e. not really spelled out there). But I wouldn’t wanna use something like “conventional commits”. Mostly because I don’t like the convention it uses. But also because it seems to rely too much on the log, i.e. you end up with duplication. (A changelog that closely mimics git-log is convenient (again) but I also would want to sprinkle in some end-user specific writings.) Aah, well maybe (hopefully) I get to develop some library or something which I feel deserves a changelog someday. Maybe when it gets more than two GitHub stars.