fhoekstra

joined 2 years ago
[–] fhoekstra@feddit.nl 1 points 2 days ago (1 children)

That is indeed a difficult problem. Integration testing and contract testing can help to avoid this, but one can never be 100% sure.

https://xkcd.com/1172/

[–] fhoekstra@feddit.nl 1 points 3 days ago

Nice, I hadn't heard of that one yet!

[–] fhoekstra@feddit.nl 4 points 3 days ago* (last edited 3 days ago) (1 children)

Thanks for your feedback!

Some thoughts:

  • You could configure your cliff.toml (generated with git-cliff --init) to ignore any commits that aren't interesting to your users
  • You could use "squash merge" to the prerelease/staging/development branch so that you can commit without worry, and then only have your PR titles follow conventional commits (if the change is interesting to your users)

I should probably add those to the blog.

But yeah, I get preferring to write manual tailored changelogs. Personally I am just a little neurotic about single source of truth and a huge Git nerd. And I know that at least in this job, my users are neurotic enough to prefer completeness.

 

cross-posted from: https://feddit.nl/post/45839000

Automated changelog generation

When publishing a package for use by programmers, automated changelog generation is very beneficial. In this blog post, I explore how to do it in a simple way that works everywhere.

 

cross-posted from: https://feddit.nl/post/45839000

When publishing a package for use by programmers, automated changelog generation is very beneficial. In this blog post, I explore how to do it in a simple way that works everywhere.

 

When publishing a package for use by programmers, automated changelog generation is very beneficial. In this blog post, I explore how to do it in a simple way that works everywhere.

 

First post on my personal blog!

 

cross-posted from: https://piefed.social/post/1302658

PostgreSQL 18.0 Released With Async I/O, Performance Improvements - Phoronix