Forgot the most relevant point: it can automatically include the generated release notes in the git tag that is generated which translates to release notes when pushed.
On Fri, Jan 13 2023 at 9:31 AM, Zach Daniel < zachary.s.dan...@gmail.com > wrote: > > My library git_ops https://github.com/zachdaniel/git_ops is a native > elixir solution for managing a change log with tags for releases. Im sure > it could be improved, but it’s a solid foundation that a lot of people are > using today. Plus, the conventional commit format is a well known already > specified pattern: https://www.conventionalcommits.org/en/v1.0.0/ > > > It provides a mix task that automatically determines the next version > based on the types of commits, and writes any relevant commits to a > changelog file. > > > In standardizing the changelog practices, you could also standardize the > commit/next version practices. > > > > > On Fri, Jan 13 2023 at 6:28 AM, Jonatan Männchen < jona...@maennchen.ch > > wrote: > >> Hi Everyone, >> >> I had a discussion with Andrea (@whatyouhide) about how to handle >> changelogs in elixir itself as well as core libraries.The way how those >> libraries implement changelogs is important both to auto-discovery of >> changes with auto updating tools like renovate and also because it is a >> place for guidance / inspiration for independent library creators. >> >> >> This proposal is only about the mechanism of publishing changelogs. It is >> not about the contents. >> >> >> *Current state:* >> >> >> >> * Core >> >> * Elixir >> >> * per minor release: CHANGELOG.md file >> * GitHub release is automatically created >> * Artifacts are stored in release >> * manual copy of text into GitHub release >> >> >> >> * ExDoc >> >> * global CHANGELOG.md file >> * manual copy of entry into GitHub releases >> >> >> >> * GenStage >> >> * global CHANGELOG.md file >> * no GitHub releases >> >> >> >> * ElixirMake >> >> * global CHANGELOG.md file >> * no GitHub releases >> >> >> >> >> >> >> * Phoenix >> >> * per minor release CHANGELOG.md >> * some GitHub releases were created, not up-to-date >> >> >> >> * Tzdata >> >> * global CHANGELOG.md >> * no GitHub releases >> >> >> >> * Jason >> >> >> * global CHANGELOG.md >> >> * manual GitHub releases >> >> >> >> >> * Plug Cowboy >> >> * per major version CHANGELOG.md >> >> * manual GitHub releases >> >> >> >> >> * Telemetry >> >> * global CHANGELOG.md >> * outdated GitHub releases >> >> >> >> >> >> >> >> *Possibilities for standardization:* (i can think of, reply with others if >> you think something is missing) >> >> >> >> >> * Only CHANGELOG.md >> >> * Changelogs are written by hand and not published via GitHub releases >> * Drawbacks >> >> * Hard to automatically discover changes (for example Renovate Bot) >> * not as well integrated in GitHub itself as GitHub releases >> * does not support extra artifacts like binaries >> >> >> >> * Advantage >> >> * simple >> * no extra manual labor >> >> >> >> >> >> >> * CHANGELOG.md + GitHub releases manual copy >> >> * On release the CHANGELOG.md file is extended with no information. After >> the release the notes are copied over into a new GitHub release manually. >> * Drawbacks >> >> * Needs extra manual labor >> * Entries can be missing because people forgot to do it >> >> >> >> >> >> >> * CHANGELOG.md & Automated GitHub release note >> >> * On release the CHANGELOG.md file is extended and a GitHub workflow will >> parse the CHANGELOG.md and use the text to create a release. >> * Drawbacks >> >> * Introduces some complexity & maintenance by adding CI workflows >> >> >> >> >> >> >> * GitHub releases & automatic appending of CHANGELOG.md file with release >> notes >> >> * To release a person would create a GitHub release and a workflow would >> automatically prepend the changes to the CHANGELOG.md file >> * Drawbacks >> >> * Same as the option before >> >> * Workflow is more complicated because it would need to commit code by >> itself >> * Imposes a more rigid process on the release workflow while other options >> are more flexible. >> >> >> >> >> >> >> * Only GitHub releases >> >> * Changes are only published via GitHub releases >> * Drawbacks >> >> * not portable if the community ever migrates away from GitHub >> * the CHANGELOG.md file does either not exist in published libraries or >> would need to be generated on demand out of the releases >> >> >> >> >> >> >> >> >> *My personal favorite solution so far:* >> * >> * >> CHANGELOG.md & Automated GitHub release note >> >> >> The reason for that preference is that it is relatively easy to automate >> and that it offers the best if both worlds. >> >> >> *Implementation* >> * >> * I’m happy to provide a shared action as well as PRs for all core >> libraries. >> >> >> Such a shared action could possibly be hosted at ErlEF since it could be a >> „community recommendation“. >> >> >> Thanks & Best, >> Jonatan >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/7744dfd3-e94e-45ed-bb10-ca6d5c732550n%40googlegroups.com >> ( >> https://groups.google.com/d/msgid/elixir-lang-core/7744dfd3-e94e-45ed-bb10-ca6d5c732550n%40googlegroups.com?utm_medium=email&utm_source=footer >> ). >> >> > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/lcumb1t9.9c802f47-0dde-47f3-9483-1e24ef1612b5%40we.are.superhuman.com.
