Changelog-Driven Releases

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

InfluxDB - Power Real-Time Data Analytics at Scale
Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
www.influxdata.com
featured
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com
featured
  • alkymi

    Pythonic task automation

  • I also use a similar approach for my open source Python automation project, alkymi: https://github.com/MathiasStokholm/alkymi/blob/develop/CHANG...

    In addition to the author's comments, I would suggest also using the format from https://keepachangelog.com/en/1.1.0/ (more sub-headings, e.g. "added").

    Lastly, pruning the CHANGELOG upon adding and removing stuff again is a great idea to keep entries meaningful for the reader.

  • epage

  • My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks.

    I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including

    - You can't as easily introspect the process

    - You can't as easily recover from failure

    - Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult

    - When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version

    I have been considering making a tool to generate changelogs from fragments. Been keeping notes at https://github.com/epage/epage.github.io/issues/23

    [0]: https://github.com/crate-ci/cargo-release

    [1]: https://github.com/MarcoIeni/release-plz/discussions/1019

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

    InfluxDB logo
  • cargo-release

    Cargo subcommand `release`: everything about releasing a rust crate.

  • My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks.

    I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including

    - You can't as easily introspect the process

    - You can't as easily recover from failure

    - Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult

    - When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version

    I have been considering making a tool to generate changelogs from fragments. Been keeping notes at https://github.com/epage/epage.github.io/issues/23

    [0]: https://github.com/crate-ci/cargo-release

    [1]: https://github.com/MarcoIeni/release-plz/discussions/1019

  • release-plz

    Publish Rust crates from CI with a Release PR.

  • My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks.

    I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including

    - You can't as easily introspect the process

    - You can't as easily recover from failure

    - Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult

    - When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version

    I have been considering making a tool to generate changelogs from fragments. Been keeping notes at https://github.com/epage/epage.github.io/issues/23

    [0]: https://github.com/crate-ci/cargo-release

    [1]: https://github.com/MarcoIeni/release-plz/discussions/1019

  • towncrier

    Manage the release notes for your project.

  • I don't really like writing the change log automatically from commits. I think those both have a slightly different audience and thus need different wording.

    I know the frustration of merge conflicts on the change log file.

    Right now, I'm creating change logs by hand which is time consuming to do on release time. I'm considering switching to using towncrier or something similar, where you have a changes dir with one file per change for creating change logs --> https://towncrier.readthedocs.io/

  • SaaSHub

    SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

    SaaSHub logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • Encapsulation in Rust and Python

    4 projects | dev.to | 5 Apr 2024
  • Rust Bindings for the Python Interpreter

    1 project | news.ycombinator.com | 20 Feb 2024
  • Segunda linguagem

    3 projects | /r/brdev | 10 Dec 2023
  • Calling Rust from Python

    2 projects | news.ycombinator.com | 8 Oct 2023
  • Bytewax: Stream processing library built using Python and Rust

    2 projects | news.ycombinator.com | 25 Jul 2023