Skip to content

v0.3.341
Compare
Choose a tag to compare
@ap0llo ap0llo released this 18 Jan 17:22
v0.3.341
f4882ef

New Features

Bug Fixes

Breaking Changes

Details

Add JSON Schema for the configuration file.

Add a JSON Schema for the configuration file to provide auto-completion support when editing the file in editors that support JSON Schema (e.g. Visual Studio Code).

GitHub Integration: Add project settings for GitHub integration

Add settings to customize how the GitHub integration loads project information from a repository.

Add "Remote Name" setting to customize which remote URL is parsed to find the repository on GitHub. Previously the GitHub integration always used the 'origin' remote. By default, 'origin' continues to be used.

Additionally, add settings to specify the GitHub host name, repository owner name and repository name which overrides the values parsed from the remote URL. By default, these settings are empty and all GitHub project information is read from the remote URL.

GitLab Integration: Add project settings for GitLab integration

Add settings to customize how the GitLab integration loads project information from a repository.

Add "Remote Name" setting to customize which remote URL is parsed to find the repository on GitLab. Previously the GitLab integration always used the 'origin' remote. By default, 'origin' continues to be used.

Additionally, add settings to specify the GitLab host name, project namespace and project name which overrides the values parsed from the remote URL. By default, these settings are empty, and all GitLab project information is read from the remote URL.

Support filtering of change log entries

Breaking Change: The "Entry Types" setting no longer influences which entries are included in the change log but only changes the display name for entry types.

Add "Filter" setting that allows to customize which entries are included in the generated change log.
Change log entries can be filtered by matching an entry's type and/or scope with support for wildcards.

The default filter includes all entries of type 'feat' or 'fix' (retaining the default behaviour of previous versions).

The "Entry Types" setting which previously specified which entries to include in the output remains in place but now only influences the display name of an entry type. This makes the "Entry Types" setting consistent with the "Footers" and "Scopes" settings.

Allow overriding settings for individual footers

Breaking Change: The format of the 'footers' setting in the configuration file has changed. Configuration files intended for v0.2 need to be updated to the new format manually.

Changes the 'footers' setting in the configuration file from a JSON array to a JSON object. The settings for a specific footer are now modeled as a property on the JSON object named like the footer the settings apply to.
This allows overriding the settings for a specified footer based on its name rather than its position in the list (when specifying footer settings as environment variables).

Include display name for common footers in default configuration

In the default configuration, provide display names for common foooters "see-also", "closes", "fixes", "co-authored-by", "reviewed-by", "pull-request" and "merge-request".

Allow overriding individual scope display names

Breaking Change: The format of the 'scopes' setting in the configuration file has changed. Configuration files intended for v0.2 need to be updated to the new format manually.

The 'scopes' setting in the configuration file was changed from a JSON array to a JSON object. The settings for a specific scope are now modeled as a property on the JSON object named like the scope the settings apply to.
This allows overriding the settings for a specified scope based on its name rather than its position in the list (e.g. when specifying scope settings as environment variables).

Allow overriding individual entry type display names

Breaking Change: The format of the 'entryTypes' setting in the configuration file has changed. Configuration files intended for v0.2 need to be updated to the new format manually.

The 'entryTypes' setting in the configuration file was changed from a JSON array to a JSON object. The settings for a specific entry type are now modeled as a property on the JSON object named like the entry type the settings apply to.
This allows overriding the settings for a entry type based on its name rather than its position in the list (e.g. when specifying settings using environment variables).

Add settings to configure the order in which different type of entries are shown in the change log

In version 0.2, the order in which entries were shown was determined by the order in which the entry types were configured.
With the change of the configuration format (introduced as part of the filtering feature), the order in the configuration can no longer be used because the configuration is no longer an array with a defined order.

To make the order in which different types of entries appear configurable, a 'priority' setting for entry types was added.
Entries of types with a higher priority will appear in the output first. A entry type's default priority is 0 so entries without priority will appear last.

The default configuration includes priorities for entries of type 'feat' and 'fix' to ensure new features appear before bug fixes.

Include display names and priorties for common entry trypes in default configuration

Include display names and priorities for entry types 'feat', 'fix', 'perf', 'docs', 'refactor', 'test', 'build', 'ci', 'style', 'chore' in the default configuration.
By including default values, the generated change log shows entries with sensible headings in a sensible order if entries other than 'feat' and 'fix' are included in the output by adjusting the filter without the need to always adjust entry type settings.

Support linking between change log entries

Add support for referencing other change log entries from change log entry footers using the entry's git commit id.
When a footer value is a valid git commit id and refers to a commit for which the change log contains an entry, the footer's value will be replaced with a link to the referenced change log entry.
Instead of the commit hash, the referenced entry's summary will be used for the link's text.

Add .NET 5 support

Add support for running changelog on .NET 5.
Running on .NET Core 2.1 and .NET Core 3.1 continues to be supported.

Building this repository will require the .NET 5 SDK going forward.

Auto-locate the repository directory

Make the 'repository' command line parameter optional.
When no repository path is specified, the current directory will be probed for a git repository.
If the current directory located within a git repository, a change log for the current repository will be generated.

GitHub Integration: Improve error handling

Gracefully handle errors during communication with GitHub instead of crashing.
When the GitHub API rate limit is exceeded, provide a specifc error message and suggest to use an access token to get a higher rate limit.

GitHub Integration: Add web links for commit references in footers

When a footer's value is a reference to a git commit and GitHub integration is enabled, render the footer as link to the referenced commit in the GitHub web interface.

GitLab Integration: Add web links for commit references in footers

When a footer's value is a reference to a git commit and GitLab integration is enabled, render the footer as link to the referenced commit in the GitLab web interface.

Render urls in footers as links

When a footer's value is a http or https url, it will be included in the change log as link.

Add normalization of references

Add normalization of commit, GitHub and GitLab references. which converts the text of these references to a standardized format when possible.

Fix endless recursion in Equals() implementation of CommitMessageHeader

Templates: Fix linking in GitHubRelease template

When using the GitHubRelease template, include anchor tags in the markdown document in order to make linking to specific change log entries from the summary list work

Recognize two-segment version numbers in tags

Adjust default tag patterns to recognize two-segment (like '1.0') versions in tags.
Before this change, only full three-segment semantic versions (like '1.0.0') wer recognized.

Assets 3
Loading