All notable changes to this project are documented in this file.
The format is based on Keep a Changelog, and this project adheres to Semantic Versioning. The file is auto-generated using Conventional Commits.
- unreleased
0.4.0
– 2020.08.160.3.0
– 2020.03.140.2.0
– 2019.09.170.1.1
– 2019.08.120.1.0
– 2019.08.12
nothing new to show for… yet!
0.4.0 – Commit scope templating
2020.08.16
You can use the scope
template function to print the scope of a
commit.
A typeheader
filter exists to use custom scope names. Use the
scope_headers
config flag as such:
<!--
Config(
scope_headers: {
"ui": "User Interface",
}
)
-->
This feature is similar to the already existing type
function.
See the default template file for an example of the
type
feature, which should give you an idea on how to use scope
and
its configurables.
This release is made possible by the following people (in alphabetical order). Thank you all for your contributions. Your work – no matter how significant – is greatly appreciated by the community. 💖
- Jan Christian Grünhage ([email protected])
-
provide scopeheader filter (
99695ca
)This filter is analogous to the typeheader filter, it maps from a scope to a scope name suitable for changelog headers, with the map configurable from the config section.
-
expose commit scope during templating (
65bab03
)
0.3.0 – More templating functionality
2020.03.14
The Tera dependency was upgraded from 1.0.0-beta.15
to 1.1.0
,
which brings with it a list of new features to use in the changelog
template.
Additionally, a bug causing git tags to be incorrectly sorted got squashed.
This release is made possible by the following people (in alphabetical order). Thank you all for your contributions. Your work – no matter how significant – is greatly appreciated by the community. 💖
- Jean Mertz ([email protected])
- sort list of git tags (
a4bbbdc
)
-
update Tera dependency to v1.1.0 stable (
f2c9f38
)This allows for more functionality to be used while templating the CHANGELOG.
See the Terra changelog for more details.
0.2.0 – Final release with required release title
2019.09.17
Because coming up with a release title for every new release is hard, so the next release will have a way to not have a release title, but still have release notes.
On to the release itself.
This is mostly a release full of fixes as reported by @mmstick, @Calmynt and @kondanta. Thank you all!
Aside from a slew of bug fixes, the biggest new feature is support for
tags starting with a v
, so both 0.1.0
and v0.2.0
tags are now
recognised as release tags.
Enjoy!
This release is made possible by the following people (in alphabetical order). Thank you all for your contributions. Your work – no matter how significant – is greatly appreciated by the community. 💖
- Jean Mertz ([email protected])
-
assign commits to correct release (
b101f8c
)The algorithm to determine if a commit belongs to a specific release is incorrectly assigning commits to the wrong releases for any release except the first one.
It iterates over all commits with an enumerator attached, then skip any commits belonging to previous releases, then skipping the commits belonging to the current release, and finally uses the new enumerator value as the count for the number of commits belonging to the release.
This is incorrect, as the enumerator shouldn't start counting until after skipping the commits not belonging to the current release.
This is fixed by simplifying the iterator logic to count the relevant commits.
-
add newline between release date and notes (
e7e88b7
) -
ignore non-conventional commits (
ceabf81
)The documentation states that non-conventional commits are ignored in the final release notes, but this was not actually the case. It is now.
The "other" commits are ignored by Jilu and won't show up in the change log.
-
remove extra whitespace at end of commit (
7ffd865
)The git2 library adds a newline at the end of commit messages, even if the message is a single line. This makes sense when printing it to the screen, but not for our parser.
Our parser either accepts a single line commit:
feat: my commit message
Or a multi-line commit with a blank line between the subject and the body:
feat: my commit message with a commit body!
In the first case, git2 adds a newline after the subject, which falls between the first and second case, and is thus considered invalid.
The solution is to always trim any extra whitespace at the end of the commit message.
-
split contributors per line (
3948e9c
)The default template didn't add a newline after each contributor, breaking the rendered markdown.
-
deduplicate list of contributors (
adbabcf
)
-
better tag support (
6b79f87
)Tags can now start with or without a leading
v
(e.g. v0.1.0).Also, tags can now be both lightweight or annotated, whereas before non-annotated tags returned an error.
When using non-annotated tags, a release won't have a title or a custom release description.
-
update to new conventional commit parser (
9ca8143
)The new parser uses the Nom library for improved accuracy and zero allocations with fewer dependencies.
0.1.1 – The Quick Fix
2019.08.12
What goes up, must come down.
This release fixes several issues that came to light after releasing
v0.1.0
, which put the repository in a state with no unreleased
changes, triggering branching logic that still had a few bugs 🐛.
Those bugs are no more.
Still, this is a perfect reminder to start working on those unit tests.
This release is made possible by the following people (in alphabetical order). Thank you all for your contributions. Your work – no matter how significant – is greatly appreciated by the community. 💖
- Jean Mertz ([email protected])
-
prevent subtraction with overflow (
2e383d1
)Return early if there are no commits to take from the stack.
-
correctly check for no new changes (
61ceeed
)Since
unreleased
is an object, it never reports back as being falsy, so we instead check for an empty list of changes in the object.
0.1.0 – Ship It!
2019.08.12
The first release of Jilu 🎉.
Jilu is a tool that generate a change log for you, based on the
state of your Git repository. It converts conventional commits into a
human readable change log, using Git tags to annotate your
releases with titles, release notes and more. You can tweak your
change log to suit the needs of your community and even integrate the
jilu
binary into your CI workflow for automated updates.
This release is an example of using an annotated Git tag to attach a custom release title (in this case "Ship It!") and a hand-written release note (this message) to a release. This makes it more pleasant for your readers to get up-to-date on what has changed, while also providing them with an accurate list of all the relevant changes part of the release (which for this project means all commits with the types "feat", "fix" or "perf").
Since the notes are inlined into the change log, you can use markdown and have it render as expected. Don't go too crazy with this though, as people might not always read your tag annotations from a client that can render Markdown text to HTML. And while that is the exact purpose of markdown (being easy to read in non-rendered form), you can still get too carried away, making your notes less readable than they could be.
You can also embed images to give more visual appeal to your release notes, as a picture is worth a thousand words when you want to let your audience know about all those amazing new features.
Now first I'm going to automatically (really! 🙈) thank myself for my contributions (there will be a feature to exclude certain core contributors from getting thanked all the time), and then I invite you to go read the changes below, and hopefully you find any use for this tool, as I have.
Be sure to check out the project README if you haven't already!
This release is made possible by the following people (in alphabetical order). Thank you all for your contributions. Your work – no matter how significant – is greatly appreciated by the community. 💖
- Jean Mertz ([email protected])
-
show commit type of unreleased changes (
10a3e99
)The goal is to keep the list of unreleased changes more succinct, but still provide enough information to see the most important upcoming changes at a glance.
With this change, the commit type is added to the single-line description of each change, giving better insight into how relevant each change is.
When breaking changes are added to the change log, that too should somehow be conveyed in the upcoming changes list, so people can anticipate these breaking changes by reading the change log.
-
configurable change log template and config (
d462839
)It's now possible to alter the way your change log looks by combining a set of configuration settings and an optional custom template system.
The eventual goal is to support both use cases of making simple changes to the default template to suit your needs by using configuration settings, or to style your change log from scratch using your own template.
Template support is fully supported with this change, and the first set of configuration settings are also added. More will follow in the future.
-
initial working version (
c62baf6
)This is a first "working" version of the
jilu
application.There are still many things to do, and there are still some hard-coded debug variables in the source code, but it's good to get it out there, and iterate on it from here on out.
The three next big steps are:
- Improve testing setup.
- Expose configurables.
- Expand documentation.
But it's out there, yay! 🎉 💃🏽
-
chronologically order release changes (
fa7f5a5
)Changes within a change set weren't ordered from newest to oldest, as was supposed to happen, this is now fixed.
As an added bonus, this changes the commits returned by
git::commits
from a linked-list to a regular vector of chronologically ordered commits, improving performance and reducing complexity.