4 ms·

I don't quite understand the use case for this sort of app (generating a nice changelog from a well structured commit history.) In my experience if your team is

I don't quite understand the use case for this sort of app (generating a nice changelog from a well structured commit history.) In my experience if your team is disciplined enough to use something like Conventional Commit rigorously you don't actually need an app. The history of the merge commits or pull request descriptions is usually enough, unless you're passing the changelog to particularly non-technical users, in which case you need a human to write the changelog regardless. For an app to be useful you need to have a case where you want the data from the commit history to be useful in the context of a doc, where you retain technical descriptions written by devs. Just copying the commit descriptions into a doc, even in a nicer format, feels like theatre to me. You aren't gaining anything. Non-technical users won't benefit from it and everyone else can learn 'git log'. There is an arguement that using this would push a dev team to improve their commits, but in my experience if the team lack enough discipline to write them well a time saving tool isn't enough to push them to get better. They're probably not writing a useful changelog yet, so this doesn't save any time at all. I really hope I'm missing something.

CGamesPlay 2y ago
> Just copying the commit descriptions into a doc, even in a nicer format, feels like theatre to me. You aren't gaining anything. Non-technical users won't benefit from it and everyone else can learn 'git log'. I disagree. As a technical user who consumes many external repositories, I much prefer reading a changelog to reading a list of commits. First, I'm not reading this in a git client; I'm reading it in a web browser (likely on Github). In this interface, being able to see via headings the changes since my current version and the new version is extremely useful. Second, the change log is distributed with the application, even in cases where the source code isn't (this is especially useful when thinking about things like GUI auto-update checks, where I want to see the change log before I decide to upgrade). Third, the one-line summaries typically link back to commits or PRs, so when I see something I do want more information about, I can easily find the technical discussion about it.
Jochim 2y ago
I think it serves a few potential purposes: It provides a solid, accurate draft that can be expanded on when targeting non-technical users. I've often found that lack of visibility leads to messy commits. Surfacing these messages in the changelog introduces an incentive to take more care. With regards to the usefulness of the descriptions, the associated issue is often linked along with the commit message. This is often omitted in hand-written changelogs. In this case the auto-generated changelog acts as an index, allowing the reader to quickly parse what changed and jump to the associated code or ticket.
lloydatkinson 2y ago
> I don't quite understand the use case for this sort of app (generating a nice changelog from a well structured commit history.) In my experience if your team is disciplined enough to use something like Conventional Commit rigorously you don't actually need an app. > Just copying the commit descriptions into a doc, even in a nicer format, feels like theatre to me. You aren't gaining anything. Non-technical users won't benefit from it and everyone else can learn 'git log'. > I really hope I'm missing something. Yes, this seems to be cynical for the sake of cynicism. The point of tools like this is that you do in fact want this document, because no one will be copy pasting messages from git log to put in the changlog files. And if they are, they would appreciate a tool to do it for them. Additionally, changelogs are part of releases and will show up in GitHub releases, package managers, etc.
e12e 2y ago
Going through prs generated by GitHub dependabot - I very much appreciate projects that provide release notes/change logs that highlight breaking changes. It would require a lot of work to go through each individual project for actual commit history between foo v1.2.4 and v1.3.2. Now you could argue that one should look at all dep code changes... But it's a tall order to fully audit all dependencies.

CGamesPlay 2y ago

> Just copying the commit descriptions into a doc, even in a nicer format, feels like theatre to me. You aren't gaining anything. Non-technical users won't benefit from it and everyone else can learn 'git log'. I disagree. As a technical user who consumes many external repositories, I much prefer reading a changelog to reading a list of commits. First, I'm not reading this in a git client; I'm reading it in a web browser (likely on Github). In this interface, being able to see via headings the changes since my current version and the new version is extremely useful. Second, the change log is distributed with the application, even in cases where the source code isn't (this is especially useful when thinking about things like GUI auto-update checks, where I want to see the change log before I decide to upgrade). Third, the one-line summaries typically link back to commits or PRs, so when I see something I do want more information about, I can easily find the technical discussion about it.

Jochim 2y ago

I think it serves a few potential purposes: It provides a solid, accurate draft that can be expanded on when targeting non-technical users. I've often found that lack of visibility leads to messy commits. Surfacing these messages in the changelog introduces an incentive to take more care. With regards to the usefulness of the descriptions, the associated issue is often linked along with the commit message. This is often omitted in hand-written changelogs. In this case the auto-generated changelog acts as an index, allowing the reader to quickly parse what changed and jump to the associated code or ticket.

lloydatkinson 2y ago

> I don't quite understand the use case for this sort of app (generating a nice changelog from a well structured commit history.) In my experience if your team is disciplined enough to use something like Conventional Commit rigorously you don't actually need an app. > Just copying the commit descriptions into a doc, even in a nicer format, feels like theatre to me. You aren't gaining anything. Non-technical users won't benefit from it and everyone else can learn 'git log'. > I really hope I'm missing something. Yes, this seems to be cynical for the sake of cynicism. The point of tools like this is that you do in fact want this document, because no one will be copy pasting messages from git log to put in the changlog files. And if they are, they would appreciate a tool to do it for them. Additionally, changelogs are part of releases and will show up in GitHub releases, package managers, etc.

e12e 2y ago

Going through prs generated by GitHub dependabot - I very much appreciate projects that provide release notes/change logs that highlight breaking changes. It would require a lot of work to go through each individual project for actual commit history between foo v1.2.4 and v1.3.2. Now you could argue that one should look at all dep code changes... But it's a tall order to fully audit all dependencies.