Strategies for use changelogs and bump versions

Hi!
I usually keep changelogs for my projects because I think they are really useful, not only to track the changes and not to be lost between them, but also to share with work mates or even to share with the project managers.

I follow different strategies to track the changes and it always depends of some facts, for example:

  • If I already release a first version of the project, I apply the semantic versioning specification. So I try to keep a changelog related with the version.
  • But sometimes I have not release a version yet, because it is a project under development of the first version or we don’t consider it to have the features needed to be considered as 0.1.0 version. In these cases I also write a changelog, but usually date-based. For example, I am working in a #nerves project in which I have not released a first version of the firmware yet, but I have to present the changes and new features done or in which I am working, so I attached to the release file name a date and then in the changelog I track what is done in this version.

I also have used another strategies but I am interested to know what others do and how they usually track the changes, because it is probably that I could improve my workflow knowing more about how other developers works.

Of course, there are practices that I don’t seem very useful, like the changelogs that are composed of commits, because I think it can be confused and for that I can see directly the commits made in the repository.

I usually work with #elixir so I am also interested in tools that can help to use changelogs or even to bump the version (something that sometimes I miss because I am bit clueless hehe). I searched on Hex for “changelog” and I found some packages to work with that, like git_ops (git_ops | Hex) and version_release (https://hex.pm/version_release).

I already have some pending reading, like Keep a Changelog, that seems a spec for writing changelogs with useful advices. If you know some interesting reading about it, I will be really grateful if you share it here.

And, as an extra (:joy:) bonus question: if you a project in which you are working that it is not prepared yet to be considered as a 0.1.0 version but you have to show to your work mates and to the project manager, do you think it would be appropriate and useful to present them as release candidate versions?

I wish someone finds this topic as interesting as it is for me :smiling_face_with_three_hearts:

If I would decide then I would like to have something between Keep a Changelog and Elixir/Phoenix changelog files.

  1. Firstly I would use a text from Keep a Changelog as a top information:
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](keepachangelog.com),
This project adheres to [Semantic Versioning](semver.org).
  1. Secondly based on Elixir and Phoenix repositories I would like to split a CHANGELOG.md between branches, so it would not be too long.

  2. From Elixir changelog a -dev release would be a huge inspiration as well as -rc. (release candidate) naming

  3. I would link related wikis, issues and pull requests

  4. Finally again following Elixir and Phoenix repositories I would like to link to a previous CHANGELOG.md file in other branch

Yeah, I also think that mentioning commits does not makes sense. Instead I would like to have a quick links to:

  1. Wiki which describes the features of application from user perspective
  2. Issue which describes the features from developer perspective
  3. PR which describes implementation details

The PR itself contains all lists of commits and references Issue. The Issue also references to Wiki. This way everyone can quickly navigate between Release/Changelog, PR (implementation), Issue (dev discussion) and Wiki (user needs), so the whole project stays clean and allows everyone to understand the project at all levels.

Something like:

## v1.1.0-dev

### Features

#### App name (in case umbrella)

##### Feature name

* **User perspective**: wiki#1
* **Developer perspective**: issue#1
* **Implementation details**: pr#1, pr#2, … (more than one in case of PR for each bug fix)

### Enhancements

#### App name (in case umbrella)

##### Enhancement name

* **User perspective**: wiki#2
* **Developer perspective**: issue#2
* **Enhances**: issue#1
* **Implementation details**: pr#3

### Bug fixes

#### App name (in case umbrella)

##### Bug name

* **Developer perspective (i.e. bug report)**: issue#4
* **Affect feature/enhancement**: issue#1
* **Implementation details**: pr#4

### 3. Soft deprecations (no warnings emitted)

#### App name (in case umbrella)

##### Deprecated feature/enhancement

* **Deprecates**: issue#5
* **In favor of**: issue#6

### Hard deprecations

#### App name (in case umbrella)

##### Deprecated feature/enhancement

* **Deprecates**: issue#5
* **In favor of**: issue#6

## v1.0

The CHANGELOG for v1.0 releases can be found [in the v1.0 branch](<link to changelog in 1.0 branch>).

As above 0.1.0-dev branch and it’s README.md file.

2 Likes