Our great sponsors
-
standard-version
:trophy: Automate versioning and CHANGELOG generation, with semver.org and conventionalcommits.org
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
conventional-changelog-config-spec
a spec describing the config options supported by conventional-config for upstream tooling
-
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.
Probably the most common option, or at least most readily available, is to pull your commit messages since the last release and package it all up. You have tools and formats such as conventional commits combined with standard version can auto-generate changelogs for you. NodeJS's changelog maker does the same thing in one package. GoReleaser has a built-in release notes tool that acts very similarly.
Twisted's Town Crier is a generic tool
For example, Changie uses itself for its own Changelog management. You can view the resulting CHANGELOG, changes directory and the GitHub release action publishing GitHub releases.
By far the most common method of versioning is semantic versioning. This is the preferred method if your project needs to keep some form of compatibility with previous versions. Alternatives are calver or my own hashver but for this article, I will be assuming semantic versioning.
Customization: Using commit messages rely on a rather strict input and output system. Customizing these can be difficult if possible at all. Conventional changelog spec can be found here but if you wanted to add a new field it is not possible.