I agree, the changelog needs to be able to be modified after the fact. With `git_ops` today , it allows you to modify the changelog before committing and pushing (or just to run that whole flow yourself, it spits out the commands to run). But it doesn't support modifying the release notes that get added to the tag at this point. But it could be added I'm sure! I agree it would be a pretty big change, my feelings won't be hurt or anything đ if people decide not to use it, but its at least an example of an attempt to solve for/standardize some of these kinds of things.
On Fri, Jan 13, 2023 at 10:12 AM, Jonatan Männchen < jona...@maennchen.ch > wrote: > > Cool library, I definitely have to check that one out for some of the > internal projects I'm working on. > > > I did think about Conventional Commits when writing this proposal but > decided to only include the publishing mechanism and not the contents of > the changelog / release notes. > The reason for this is, that something like Conventional Commits is a big > change in the development / workflows of the affected projects. > > > If all involved parties are open to this massive change, it would open the > doors for a lot of pre-existing tooling like your library or Googles > release please. > > > I'm not convinced myself that Conventional Commits are the way to go for > projects like those. The main issue I have with the convention is that > commits don't necessarily describe the intention of changes well. One > could for example make 5 commits about a specific topic but describe it as > one change in the release notes. > On Friday, January 13, 2023 at 3:32:41 PM UTC+1 zachary....@gmail.com > wrote: > > >> 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.... @ gmail. com > >> wrote: >> >> >>> My library git_ops https:/ / github. com/ zachdaniel/ 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/ ( >>> 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 < jon... @ 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 ( http://changelog.md/ ) file >>>> * GitHub release is automatically created >>>> * Artifacts are stored in release >>>> * manual copy of text into GitHub release >>>> >>>> >>>> >>>> * ExDoc >>>> >>>> * global CHANGELOG. md ( http://changelog.md/ ) file >>>> * manual copy of entry into GitHub releases >>>> >>>> >>>> >>>> * GenStage >>>> >>>> * global CHANGELOG. md ( http://changelog.md/ ) file >>>> * no GitHub releases >>>> >>>> >>>> >>>> * ElixirMake >>>> >>>> * global CHANGELOG. md ( http://changelog.md/ ) file >>>> * no GitHub releases >>>> >>>> >>>> >>>> >>>> >>>> >>>> * Phoenix >>>> >>>> * per minor release CHANGELOG. md ( http://changelog.md/ ) >>>> * some GitHub releases were created, not up-to-date >>>> >>>> >>>> >>>> * Tzdata >>>> >>>> * global CHANGELOG. md ( http://changelog.md/ ) >>>> * no GitHub releases >>>> >>>> >>>> >>>> * Jason >>>> >>>> >>>> * global CHANGELOG. md ( http://changelog.md/ ) >>>> >>>> * manual GitHub releases >>>> >>>> >>>> >>>> >>>> * Plug Cowboy >>>> >>>> * per major version CHANGELOG. md ( http://changelog.md/ ) >>>> >>>> * manual GitHub releases >>>> >>>> >>>> >>>> >>>> * Telemetry >>>> >>>> * global CHANGELOG. md ( http://changelog.md/ ) >>>> * outdated GitHub releases >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *Possibilities for standardization:* (i can think of, reply with others if >>>> you think something is missing) >>>> >>>> >>>> >>>> >>>> * Only CHANGELOG. md ( http://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 ( http://changelog.md/ ) + GitHub releases manual copy >>>> >>>> * On release the CHANGELOG. md ( http://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 ( http://changelog.md/ ) & Automated GitHub release note >>>> >>>> * On release the CHANGELOG. md ( http://changelog.md/ ) file is extended >>>> and a GitHub workflow will parse the CHANGELOG. md ( http://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 ( >>>> http://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 ( >>>> http://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 ( http://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 ( http://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-co... @ 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+unsubscribe@ googlegroups. com ( > elixir-lang-core+unsubscr...@googlegroups.com ). > To view this discussion on the web visit https:/ / groups. google. com/ d/ > msgid/ elixir-lang-core/ 603e9638-34bf-4cb6-ae75-c308322d6fbfn%40googlegroups. > com ( > https://groups.google.com/d/msgid/elixir-lang-core/603e9638-34bf-4cb6-ae75-c308322d6fbfn%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/lcuoputj.cbc983df-a06f-49bd-afc0-40fd1267510d%40we.are.superhuman.com.
