Giters

Colin-b / keepachangelog

Convert keep a changelog markdown file into python dict

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support a changelog file which doesn't use "sub sections" like "added", "changed" ...

Gustry opened this issue · comments

commented

Hi,

I'm aware, this request is not following exactly the convention https://keepachangelog.com/en/1.1.0/ but in some projects, there isn't some sub-sections like "Added", "Changed", "Deprecated".

Would it be OK to support this kind of file in this project or do you want to use only the convention ?

# CHANGELOG

## 0.5.0 - 2021-02-19

* A
* B
* C

## 0.4.0 - 2021-01-21

* D
* E
* F

Let me know what you think ?

commented

Isn't keepachangelog.to_raw_dict providing what you want?

commented

Ah yes, this is nearly ok indeed :)
I didn't know this function, it's not documented on https://github.com/Colin-b/keepachangelog/blob/develop/README.md

Maybe a list, without trailing - or * (same processing as to_dict) ?
but then it's not to_raw ... :)

Thanks for this info

commented

I can have a look later on :) Yes it's not yet documented as it's new and even released, I would rather document "stable" stuff ;)

However I will document it for next release :)

commented

Documentation is now up to date. However I keep this ticket open as I plan to add "uncategorized" section to to_dict to manage this case. Would that suit your need ?

commented

Oh yes, it would good I think.

So maybe the same time, there should a list of sub section found ? So we know which keys we can retrieve ? (because some keys will be about metadata, not about the changelog itself).

commented

I am not sure there will be a need for the metadata information (you mean the content before the first release right?)?

commented

I mean metadata such as url, semantic_version, release_date etc.

    "1.0.1": {
        "sub_sections": ["fixed"],
        "fixed": [
            "Bug fix 1 (1.0.1)",
            "sub bug 1",
            "sub bug 2",
            "Bug fix 2 (1.0.1)",
        ],
        "release_date": "2018-05-31",
        "version": "1.0.1",
        "semantic_version": {
            "major": 1,
            "minor": 0,
            "patch": 1,
            "prerelease": None,
            "buildmetadata": None,
        },
        "url": "https://github.test_url/test_project/compare/v1.0.0...v1.0.1",
    },

As these subsections are "data defined", so it might help people to know which keys they can access to.

Note the line above :

"sub_sections": ["fixed"],

Someone could come with a changelog like

## 1.0.0 - 2021-05-25

### Software

### Documentation

* Feature in the documentation
* ```
But feel free to skip, it was just a side note.
`uncategorized` key is already ok for me.
commented

You can already rely on the fact that this list is everything except version, release_date, url, semantic_version. But I get your point, that would allow for the addition of new metadata keys without impacting clients.

This change would be a breaking change, thus a version 2.0.0 of this module. While I have nothing against it, I will consider every other features that might come at the same time, to avoid another breaking change release.

It might also be a good time to consider moving all those metadata to a specific sub section, so that only one key is to be ignored if you only want the changelog sections of a release. I created a discussion for this in #26

commented

except for the discussion still ongoing, the change is implemented in develop branch and will be part of next release

commented

Release 2.0.0.dev0 is now available with this change on pypi.

commented

Thanks a lot for the quick development !