Why did `npx commit-and-tag-version` miss the most recent commit?

[ramonrails]

I have the following commits in a git repo

* b834d91 - (HEAD -> main, tag: v1.3.1) chore(release): 1.3.1
* 5edaef6 - refactor(utilities): utility scripts each moved to their seperate scripts inside subfolder
* 6b76a6c - fix(git): app-tag script skips the run when no relevant changes are detected
* 8b21c9d - (tag: v1.3.0) chore(release): 1.3.0
* e27d1d1 - feat(ansible): ansible moved to devops folder
* 8b308bf - (tag: v1.2.3) chore(release): 1.2.3
* 240d0cf - (tag: v1.2.2) chore(release): 1.2.2
* d07d01e - (tag: v1.2.1) chore(release): 1.2.1
* db633c8 - (tag: v1.2.0) chore(release): 1.2.0
* a0bb9b8 - feat(ansible): ansible script moved to devops/ansible
* 8d41f0a - feat: playbook separated into file and converted to a function
* c6096a7 - (tag: v1.1.1) chore(release): 1.1.1
* c26875d - (tag: v1.1.0) chore(release): 1.1.0
* 3737bbf - feat: ansible playbook script converted to a function
* 5639760 - feat: disk_usage command added based on dua-cli

But my changelog does not show the top most commit in the v1.3.1 run.

* 5edaef6 - refactor(utilities): utility scripts each moved to their seperate scripts inside subfolder

I just ran npx commit-and-tag-version
What did I miss?

The CHANGELOG.md file is the following

# Changelog

All notable changes to this project will be documented in this file. See [commit-and-tag-version](...) for commit guidelines.

## [1.3.1](...) (2024-02-28)


### Bug Fixes

* **git:** app-tag script skips the run when no relevant changes are detected ([6b76a6c](...))

## [1.3.0](...) (2024-02-28)


### Features

* **ansible:** ansible moved to devops folder ([e27d1d1](...))

## [1.2.3](...) (2024-02-28)

## [1.2.2](...) (2024-02-28)

## [1.2.1](...) (2024-02-28)

## [1.2.0](...) (2024-02-28)


### Features

* **ansible:** ansible script moved to devops/ansible ([a0bb9b8](...))
* playbook separated into file and converted to a function ([8d41f0a](...))

## [1.1.1](...) (2024-02-28)

## 1.1.0 (2024-02-28)


### Features

* ansible playbook script converted to a function ([3737bbf](...))
* disk_usage command added based on dua-cli ([5639760](...))

[ramonrails]

This behaviour is happening consistently.
Is someone else experiencing this? Or, did I really do something incorrect?

[TimothyJones]

On mobile so can’t link you, but refactor isn’t shown by default, only user facing changes (fix and feat) and anything marked as breaking are shown

[asieduernest12]

commit examaples

Supported commits 👍

fix: this will be included, case insensitive 👍
Fix: this will be included, case insensitive 👍
fix(someScope): this is included, case insensitive 👍
feat: this will be included, case insensitive 👍
feat(someScope): this is included, case insensitive 👍
Feat(someScope): this is included, case insensitive 👍
feAt(someScope): this is included, case insensitive 👍

Unsupported commits ❌

update: excluded ❌
anythingNotFeatOrFixOrBREAKING CHANGE: excluded ❌
update/someScope: excluded ❌
ci: excluded ❌

[TimothyJones]

This looks right to me. What are you expecting to be different, and why?

By default, this tool follows the conventional commit spec, which only defines feat and fix (although it does say that other types are acceptable, it doesn't define any behaviour for them).

It's perhaps not super obvious from the commit-and-tag-version docs - but if you look at the changelog generation section, it links to the conventional-commits preset, which is where the default types are defined.

If you want to customise this, you can set it in the preset options - following this spec. For example, I often re-label fix as Bug fixes and improvements.

Generally, you don't want every commit to be in the changelog - because not every change is user-facing. Of course, if for some reason you really want this, there's nothing to stop you configuring it that way.

[asieduernest12]

@TimothyJones
It definitely isn't straight forward to tell what is not supported, I litterally did bunch of commits in a throw away branch just to see which commits appear in the changelog.

i think this should be more prominent in the docs that only feat and fix are primarily supported.

on the other hand, i have looked at the preset section you referenced above and that seems helpful to allow user customization,
hovever i cannot make sense of it by glancing, If its not much trouble , would you be able to add preset examples for
update, refactor
these are the most common commit prefixes i guess and naturally i was under the assumption it is work including all commit messages in the changelog.
this way though, it might be helpful to support something like [no changelog] within a commit message to remove it from the generated changelog.

I recognized this might be easier said than done.

[TimothyJones]

Yeah, I agree the documentation needs to be improved. I’ll take a look soon- I saw you raised a PR (thank you), but really it needs an explanation rather than just a list of what appears and what doesn’t.

Conventional commits is meant to make it easy for machines to reason about the changes. It defines the inputs from the commit messages into semver, all of which are user facing changes. Only things that are user facing changes are enabled in the changelog by default.

For example, refactor is usually not user facing, so you wouldn’t want that in by default (and I’d question the boundaries of a project that did need it enabled). Similarly, if everything was enabled, it wouldn’t provide much value over the commit log.

For implementing an alternative approach to changelog generation- this tool is (by design) a thin cli wrapper around the conventional changelog libraries- supporting other approaches isn’t really within the scope. Of course; if those libraries support a new approach, it would be naturally supported here.

As an aside, why do you want this behaviour? If you had to mark changes as not in the changelog, what would be the expected behaviour if a label that we’d never seen before (say “api”) is present? What label would it get in the changelog? There are lots of cases where you wouldn’t know how to format it, or would get it wrong

[asieduernest12]

You raised valid points and to be honest i think, your implementation as of now is perfect and no additions are needed necesarilly, each committer just has to decide what they want to show up in their change logs.

I do think the readme updates are critical though because I missed it and had to do a bunch of re-reads of the docs and try a bunch of commits to find out what worked and didnt work. The pr is just a quick glance of what will show up and what wouldn't which is normally the kind of shallow info i was in need of, for further info I always dive in deeper to read more.

[TimothyJones]

Fixed by #220 which hopefully clarifies this case a bit better