Skip to main content
10 events
when toggle format what by license comment
Jun 24, 2017 at 1:03 vote accept celsomtrindade
Jun 11, 2017 at 20:58 comment added Lazy Badger You CAN generate changelog automatically from DAG, if you'll keep this task in mind on 1) selecting workflow 2) writing commit messages. I can show it with Mercurial and Branch-Per-Task workflow
Apr 11, 2017 at 20:34 comment added eidsonator I really like Keep a Changelog as a reference.
Apr 11, 2017 at 20:23 history edited amon CC BY-SA 3.0
uuh new users don't update. Unless they “upgrade” from a competing product ;)
Apr 11, 2017 at 20:21 comment added amon @CelsomTrindade I don't know any concrete resources. Many organizations have closer guidelines for changelogs or commit messages. But not everything they do will fit your use case! As a concrete example, I really like the Todoist web app changelog. And I really dislike the generic “bug fixes and performance improvements” you see as a changelog for many Android apps. For writing commit messages, I found How to Write a Git Commit Message to be quite interesting, but it may be a bit too advanced right now.
Apr 10, 2017 at 22:56 comment added celsomtrindade That's a nice point of view! It made things a lot more clear to me. This is all new and still kind of confusing, so this was very helpful. Do you have any other content you'd recomend so i can study it more?
Apr 10, 2017 at 17:29 comment added Jörg W Mittag Yeah. Linux and Git itself use git shortlog (or git log --pretty or similar) for changelogs, but that's a special situation since the "users" of Linux changelogs are distro kernel developers, and the users of Git changelogs are users of Git, who are of course developers themselves. And, of course, the Linux and Git developers know that and write their commit messages accordingly. In general, it works for stuff like web services, frameworks and libraries, where the target audience are themselves developers, but not for user-facing stuff like apps, desktop, mobile, or web.
Apr 10, 2017 at 17:27 comment added amon @JörgWMittag putting release notes into tags actually seems like a good idea, thanks! However, I merely wanted to discourage a “I know, I'll do git log >>Changes.txt” approach to generating the changelog, which tends to be useless for users if only done as an afterthought.
Apr 10, 2017 at 17:20 comment added Jörg W Mittag A couple of years ago, I had this idea of using merge commits of feature branches for changelogs. I never tried it, though. It would require you to not use fast-forwards for feature merges. That way, you could generate a changelog from the history automatically, and even correctly annotate it with versions, assuming you tag appropriately. Similarly, I thought about putting release notes in annotated tags, again making it possible to automatically generate releases directly using nothing but source files and VCS metadata.
Apr 10, 2017 at 17:08 history answered amon CC BY-SA 3.0