I'm working on some projects where I'd like to supply an accurate changelog with each release, but I haven't found a method for collecting the changelog that would work without hassle. The problem is mostly when the time between versions is long and each version ships with a lot of features and bug fixes, and when the software has several branches being developed at the same time.
Some options I've considered:
- Build the changelog from commit messages and require developers to write the messages as if they would be writing a line for the changelog (which they would effectively be doing).
- Might not work when there are multiple branches and merging between branches (might be hard to know which commits have ultimately ended up in the release).
- Require that for each change in the code there should be a corresponding ticket in the bug tracking system. The changelog could be written based on the tickets.
- The devs might find it frustrating to make a ticket for even minor changes, especially if making the ticket takes longer than fixing the bug.
- Require that the developers always update the changelog (as a text file in project root) at the same time when they make changes to the code.
- Feels like manual labor that could be automated.
- Have the project manager take the diff of the current version and the previous one and write the changelog at that point based on what they see that's been changed.
- Extra work for the person responsible for the release and it might not be obvious what the practical effect of a change is just by looking at the code.
- Ship only the features that have been planned for the release; you can write the changelog even before you start coding.
- Not a real option unless you're using the waterfall model.
I've used each of these or a variation of them in the past but they have been too unreliable, laborous or rigid. Does anyone have a magic bullet or good ideas on how to solve the problem?