Distinction between release content and metadata such as release date

[Colin-b]

As pointed out in this issue, the return value of keepachangelog.to_dict is mixing sub sections and metadata information.

To get the list of all sub sections for a particular release, you need to skip an exhaustive list of values: version, release_date, url and semantic_version.

Pro

• Metadata information is available right away in a release content.

Con

• It requires clients to maintain a fixed list of values to be able to skip those metadata.
• It prevent the addition of new metadata without issuing a new major release.

Proposed change

This is why I would like to issue a new major release allowing for a more generic parsing on client side and allowing the addition of new metadata in the future without breaking changes (one could foresee more details extracted from the url or the date).

version, release_date, url and semantic_version would be available as part as a sub dictionary in every release, under a to be defined key.

It would change the output of a specific release from:

{
    "changed": [
        "Enhancement 1 (1.1.0)",
        "sub enhancement 1",
        "sub enhancement 2",
        "Enhancement 2 (1.1.0)",
    ],
    "release_date": "2018-05-31",
    "version": "1.1.0",
    "semantic_version": {
        "major": 1,
        "minor": 1,
        "patch": 0,
        "prerelease": None,
        "buildmetadata": None,
    },
    "url": "https://github.test_url/test_project/compare/v1.0.1...v1.1.0",
}

to:

{
    "changed": [
        "Enhancement 1 (1.1.0)",
        "sub enhancement 1",
        "sub enhancement 2",
        "Enhancement 2 (1.1.0)",
    ],
    "metadata": {
        "release_date": "2018-05-31",
        "version": "1.1.0",
        "semantic_version": {
            "major": 1,
            "minor": 1,
            "patch": 0,
            "prerelease": None,
            "buildmetadata": None,
        },
        "url": "https://github.test_url/test_project/compare/v1.0.1...v1.1.0",
    },
}

[Gustry]

Looks fine to me indeed. Looks cleaner.
Even if it's not the best, I would still prefer having an explicit list of keys that I can fetch #20 (comment)
In your version above : "sub_sections": ["changed",],
But not strong opinion for this ;-)

[Colin-b]

Note that with this, we can still foresee adding this information later on to metadata

[Colin-b]

@aogier as I know you will be impacted by this change, what would be your input on this?

[Colin-b]

A dev release for version 2.0.0 (2.0.0.dev0) is now available on pypi. If no negative feedback is received (or if no change is requested), then stable release 2.0.0 will be issued. @Gustry Once stable version is released, it will be a perfect time to review if you still need this, as we could add it to metadata content.