[Question/Bug] Incomplete changelog

[hypervtechnics]

Hi,

I am currently testing your program. Thanks for coding and providing it. It looks very promising. I encountered a situation where the generated changelog differs from what I expected it to be. I'd rather not call it a bug report, because I am not sure whether I just configured something wrong. Can someone help me with this?

user@supermachine01:~/projects/sv4git-test$ git log
commit 1d3b726e0376d8674a9008fe51eed82bf97a1b12 (HEAD -> master, tag: 1.1.0, origin/master)
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Mon Jul 26 23:05:53 2021 +0200

    build: add drone ci

commit 7b7dd31ab163ea332e162ba3a03a86a5df5a07f3
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Mon Jul 26 23:01:55 2021 +0200

    fix: Fix heading

commit a23806650a4c67b6513516498e06c7ff6776f25f
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Mon Jul 26 22:58:04 2021 +0200

    feat: Add another line

commit 2068851cc1183457c00e6fda6f2df92e9f49214a
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Mon Jul 26 22:44:15 2021 +0200

    Add build to headers

commit 247c5fa0920cf8fb635e1ee324596515765cbbe5 (tag: 1.0.0)
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Sun Jul 4 18:28:51 2021 +0200

    feat!: hm

commit 480ab832801aec3201c1ed95c4b655f930efb0e9 (tag: 0.1.0)
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Sun Jul 4 18:15:27 2021 +0200

    feat(headline): Introduced new headline

commit 885d53f12ad924cfff2f3f819836176d0d059f25
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Sun Jul 4 18:14:10 2021 +0200

    build: Add sv4git

commit 7c320f006a6f578659d0b917de33311285ffc6d3
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Sun Jul 4 18:09:14 2021 +0200

    docs(readme): Fix linter error with title

commit 69c44c024b2ae88791bf8a3ea82acd451d667dc5
Author: hypervtechnics <hypervtechnics@gmail.com>
Date:   Sun Jul 4 18:08:37 2021 +0200

    Initial commit

# .sv4git.yml
version: '1.0'
versioning:
    update-major: []
    update-minor:
        - feat
    update-patch:
        - build
        - ci
        - chore
        - docs
        - fix
        - perf
        - refactor
        - style
        - test
    ignore-unknown: false
tag:
    pattern: '%d.%d.%d'
release-notes:
    headers:
        breaking-change: Breaking Changes
        feat: Features
        fix: Bug Fixes
        build: Build
branches:
    prefix: ([a-z]+\/)?
    suffix: (-.*)?
    disable-issue: false
    skip:
        - master
        - main
        - developer
    skip-detached: false
commit-message:
    types:
        - build
        - ci
        - chore
        - docs
        - feat
        - fix
        - perf
        - refactor
        - revert
        - style
        - test
    scope:
        values: []
    footer:
        issue: {}
    issue:
        regex: '[A-Z]+-[0-9]+'

The repository is pushed to a private repository and has three tags on it.

user@supermachine01:~/projects/sv4git-test$ git sv cgl
# Changelog

## v1.1.0 (2021-07-26)

### Features

- Add another line (a238066)

### Bug Fixes

- Fix heading (7b7dd31)

---

## v1.0.0 (2021-07-04)

### Features

- hm (247c5fa)

---

## v0.1.0 (2021-07-04)

### Features

- **headline:** Introduced new headline (480ab83)

---

Here I expected the Build section to be included as part of some releases.

Did I misunderstand/misconfigure something?

[hypervtechnics]

Also running sv4git cl shows that the correct type is recognized:

user@supermachine01:~/projects/sv4git-test$ git sv cl -r hash -s 69c44c0
{"date":"2021-07-26","hash":"f0d9d6c","message":{"type":"chore","description":"Refine sv4git configuration"}}
{"date":"2021-07-26","hash":"1d3b726","message":{"type":"build","description":"add drone ci"}}
{"date":"2021-07-26","hash":"7b7dd31","message":{"type":"fix","description":"Fix heading"}}
{"date":"2021-07-26","hash":"a238066","message":{"type":"feat","description":"Add another line"}}
{"date":"2021-07-26","hash":"2068851","message":{"description":"Add build to headers"}}
{"date":"2021-07-04","hash":"247c5fa","message":{"type":"feat","description":"hm","isBreakingChange":true}}
{"date":"2021-07-04","hash":"480ab83","message":{"type":"feat","scope":"headline","description":"Introduced new headline"}}
{"date":"2021-07-04","hash":"885d53f","message":{"type":"build","description":"Add sv4git"}}
{"date":"2021-07-04","hash":"7c320f0","message":{"type":"docs","scope":"readme","description":"Fix linter error with title"}}

69... is the hash of the first commit

[bvieira]

Hello, thanks for trying to use sv4git 😃

It's not exactly a bug because it's implemented to work like this, but in the future I would like to implement in a way that is possible to choose the sections in changelog and also join them in a section called misc.

Any ideas or feedback is more then welcomed!

[bvieira]

The problem right now is that release-notes.headers is a map, so it is an unordered collection and I won't be able to get the sections order from it.

I need to check if go-yaml support any kind of ordered map or custom structure, but I found some open issues related to that.

One option would be add another attribute to sort it, but I think it would be error prone. It would be easy to add a new headers and forget to add it in the order array.

release-notes:
    headers:
        breaking-change: Breaking Changes
        feat: Features
        fix: Bug Fixes
    order: [feat, fix, refactor, perf, test, build, ci, chore, docs, style,breaking-change]

Another option would be create a new attribute for sections and deprecate the headers attribute. With this, would be possible to group commit types in a single section. Breaking changes is a special case because it has only messages and not commit types.

release-notes:
    sections:
        - name: Features
          commit-types: [feat]
        - name: Bug Fixes
          commit-types: [fix]
        - name: Misc
          commit-types: [perf, docs]
        - name: Breaking Changes
          template: breaking-change

[hypervtechnics]

Thanks for your response :)

Okay then I misunderstood something. But just to be clear: I don't want to reorder or change existing sections. I want to add an additional one targeting another commit type.

If the above case is also would you mean, I think the second option would be the way to go, as it is easier to understand and also easier to handle when upgrading versions (I guess?). Although I'd suggest consolidating template and commit-types into something like content, because in the end all sections are bullet lists, right?

[bvieira]

Okay then I misunderstood something. But just to be clear: I don't want to reorder or change existing sections. I want to add an additional one targeting another commit type.

I know, but right now, the types for sections are hardcoded on the template, it would be easy to loop in the headers for each key/value but the order would be a problem..

Maybe I should just support the other types in a fixed order, and then do the refactor to support group and custom order..

Although I'd suggest consolidating template and commit-types into something like content, because in the end all sections are bullet lists, right?

no, breaking-change is not a commit type. The sections with commit types has scope, commit hash and issues, but the section for breaking change has only a message. Right now there is 2 templates for sections (breaking change and commit), but the group probably would need another one, maybe to show the commit type..

[hypervtechnics]

Wow thank you for already opening a PR regarding the functionality! 😝

Well I guess for the order you could take the order of values of the the versioning configuration? Then you would also handle user created types and still have the opt-behaviour through the headline configuration. Breaking changes could be at the top/bottom of each version notes. Grouping would then be another topic to handle. For this I think your second suggestion from above is the way to go.

In general, the second suggestion from above would be the superior one.

Anyways thank you again for directly addressing the feedback :)

[bvieira]

Well I guess for the order you could take the order of values of the the versioning configuration?

That's true, but could break retrocompatibility (current order in types is diferent from release note order).. but I think the second suggestion will be better in a long run..

[bvieira]

This feature is available in version 2.4.0!:rocket:

[hypervtechnics]

Thank you!