feat: ✨ decision post on why to use git-cliff for changelogs#273
feat: ✨ decision post on why to use git-cliff for changelogs#273lwjohnst86 wants to merge 2 commits into
Conversation
signekb
left a comment
There was a problem hiding this comment.
Very nice 🌷 Some minor suggestions:
| ::::: column | ||
| #### Drawbacks | ||
|
|
||
| - Not nearly as easily customisable as git-cliff (see below). |
There was a problem hiding this comment.
| - Not nearly as easily customisable as git-cliff (see below). | |
| - Not as easily customisable as git-cliff (see below). |
| issues and limitations to it as our needs grew. So this post is explaining why | ||
| we switched to git-cliff. See our [previous post on using Commitizen for | ||
| changelog generation](/why-changelog-with-commitizen/index.qmd) for more | ||
| information about our context and problem statement as well as the original |
There was a problem hiding this comment.
| information about our context and problem statement as well as the original | |
| information about the context and problem statement as well as the original |
| information about our context and problem statement as well as the original | ||
| reasons for using Commitizen. | ||
|
|
||
| This post explains some of our issues and why we switched to something else. |
There was a problem hiding this comment.
I think it would make sense to restate/summarise the context and problem statement here.
| information about our context and problem statement as well as the original | ||
| reasons for using Commitizen. | ||
|
|
||
| This post explains some of our issues and why we switched to something else. |
There was a problem hiding this comment.
| This post explains some of our issues and why we switched to something else. | |
| This post explains some of our issues with Commitizen and why we switched to git-cliff. |
| - The changelog generated by Commitizen is not as easy to customise. For | ||
| example, in R packages, the website generator | ||
| [pkgdown](https://pkgdown.r-lib.org/) expects a specific format for the | ||
| `NEWS.md` file, but we couldn't (easily) modify the changelog template to meet | ||
| these requirements. | ||
| - When generating the changelog to be included in the GitHub release notes, it | ||
| would often add a commit message at the end of the changelog. It wasn't clear | ||
| how to remove it or even where it came from, as the CLI didn't produce the | ||
| same output. | ||
| - We wanted to be able to customise the changelog for different projects, like | ||
| the previously mentioned R packages, but also for documentation projects, | ||
| which include a lot more changes outside of `refactor`, `fix`, and `feat`. So | ||
| some relevant changes to those repos would often be missing from the | ||
| changelog. |
There was a problem hiding this comment.
| - The changelog generated by Commitizen is not as easy to customise. For | |
| example, in R packages, the website generator | |
| [pkgdown](https://pkgdown.r-lib.org/) expects a specific format for the | |
| `NEWS.md` file, but we couldn't (easily) modify the changelog template to meet | |
| these requirements. | |
| - When generating the changelog to be included in the GitHub release notes, it | |
| would often add a commit message at the end of the changelog. It wasn't clear | |
| how to remove it or even where it came from, as the CLI didn't produce the | |
| same output. | |
| - We wanted to be able to customise the changelog for different projects, like | |
| the previously mentioned R packages, but also for documentation projects, | |
| which include a lot more changes outside of `refactor`, `fix`, and `feat`. So | |
| some relevant changes to those repos would often be missing from the | |
| changelog. | |
| - The changelog generated by Commitizen is not as easy to customise, but we need to be able to customise the changelog for different projects, like | |
| the Python packages, R packages, and documentation projects. For example, the website generator | |
| [pkgdown](https://pkgdown.r-lib.org/) for R packages expects a specific format for the | |
| `NEWS.md` file, but we couldn't (easily) modify the changelog template to meet | |
| these requirements. Documentation projects include a lot more changes outside of `refactor`, `fix`, and `feat`, and therefore | |
| some relevant changes to those repos would often be missing from the | |
| changelog. | |
| - When generating the changelog to be included in the GitHub release notes, it | |
| would often add a commit message at the end of the changelog. It wasn't clear | |
| how to remove it or even where it came from, as the CLI didn't produce the | |
| same output. |
Seems like item 1 and 3 are very closely related, so attempted to merge then.
| - Allows for filtering and pre-processing of commits based on different criteria | ||
| and patterns, which is really useful for us since we have different types of | ||
| projects that require different processing needs. | ||
| - Also written in Rust. |
There was a problem hiding this comment.
| - Also written in Rust. | |
| - Is written in Rust. |
| and patterns, which is really useful for us since we have different types of | ||
| projects that require different processing needs. | ||
| - Also written in Rust. | ||
| - It's output is consistent and predictable, which means we can incorporate it |
There was a problem hiding this comment.
| - It's output is consistent and predictable, which means we can incorporate it | |
| - produces consistent and predictable output, which means we can incorporate it |
| - Also written in Rust. | ||
| - It's output is consistent and predictable, which means we can incorporate it | ||
| easily into our workflow for generating GitHub release notes. | ||
| - It can be easily installed and used through `uv` via `uvx`. |
There was a problem hiding this comment.
| - It can be easily installed and used through `uv` via `uvx`. | |
| - Can be easily installed and used through `uv` via `uvx`. |
| ::::: column | ||
| #### Drawbacks | ||
|
|
||
| - It is primarily focused on changelog generation, so we would have to use |
There was a problem hiding this comment.
| - It is primarily focused on changelog generation, so we would have to use | |
| - Is primarily focused on changelog generation, so we would have to use |
There was a problem hiding this comment.
primarily? What's other focus areas for them?
| trade-off. | ||
| - We introduce a new dependency, which brings with it some costs to security and | ||
| maintenance. But git-cliff is actively maintained and written in Rust (which | ||
| is known for its safety), so we accept this trade-off as well. |
There was a problem hiding this comment.
Maybe there's also a consequence to be included here related to the drawback; we need to use another tool for linting and version bumping?
Description
Closes #271
Needs a thorough review.
Checklist
just run-all