Timeline for How to integrate versions with changelog?
Current License: CC BY-SA 3.0
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 |