ivanhercaz
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 (
) 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 
Most Liked
Eiji
If I would decide then I would like to have something between Keep a Changelog and Elixir/Phoenix changelog files.
- Firstly I would use a text from
Keep a Changelogas 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).
-
Secondly based on
ElixirandPhoenixrepositories I would like to split aCHANGELOG.mdbetween branches, so it would not be too long. -
From
Elixirchangelog a-devrelease would be a huge inspiration as well as-rc.(release candidate) naming -
I would link related wikis, issues and pull requests
-
Finally again following
ElixirandPhoenixrepositories I would like to link to a previousCHANGELOG.mdfile in other branch
Yeah, I also think that mentioning commits does not makes sense. Instead I would like to have a quick links to:
-
Wikiwhich describes the features of application from user perspective -
Issuewhich describes the features from developer perspective -
PRwhich 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.
Popular General Dev topics
Other popular topics
Latest in General Dev
Latest (all)
Categories:
Popular Portals
- /elixir
- /rust
- /wasm
- /ruby
- /erlang
- /phoenix
- /keyboards
- /js
- /rails
- /python
- /security
- /go
- /swift
- /vim
- /clojure
- /java
- /haskell
- /emacs
- /svelte
- /onivim
- /typescript
- /crystal
- /c-plus-plus
- /tailwind
- /kotlin
- /gleam
- /react
- /flutter
- /elm
- /ocaml
- /vscode
- /opensuse
- /ash
- /centos
- /php
- /deepseek
- /zig
- /scala
- /html
- /debian
- /nixos
- /lisp
- /agda
- /textmate
- /sublime-text
- /react-native
- /kubuntu
- /arch-linux
- /revery
- /ubuntu
- /manjaro
- /django
- /spring
- /diversity
- /nodejs
- /lua
- /c
- /slackware
- /julia
- /neovim
Devtalk Sponsors
Practical resources that improve the lives of professional developers.
We build trusted fault-tolerant systems that scale to billions of users.
Catch errors, track performance, monitor hosts and more.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"