This Pull Requests introduces initial citation meta data for this project using the Citation File Format standard. I also added the automatic validator such that one can rely on the correctness of the configuration file.

The introduced citation meta data are rendered by GitHub to a "Cite this repository" option on this project's welcome page. People interested in this project can then cite it in their papers and theses.

The meta data can be freely enriched with further fields as required. Furthermore, there is the option to add a list of references to it. This way, you can cite the used resources in order to create this project.

Please tell me whether the suggested initial meta data set is correct and if I should add further entries. For instance, there are the options to add the crate's description on crates.io as repository-artifact or to alter the URL to the documentation website. I decided to leave these options open in order to discuss the other entries, at first.

Hi, @sorairolake,

First of all, thank you for your crate! I apply it in some of my Rust binary projects and it helps me a lot to handle occurring errors.

But thereby, I encountered that a certain feature seemed to be missing: an implementation of the Display trait. This is useful in order to provide additional information for debugging but also for the resulting application itself in case an unhandled error should occur.

Thus, I would like to contribute a working implementation of the Display trait to your project. The change not only brings the implementation itself, but also a dedicated test as well as some initial documentation.

The code is already linted, formatted and checked. The commit message guidelines were applied.

Please consider to accept this change in order to add a further useful feature to your library.

Hi, @sorairolake!

I noticed that the release date given in the CITATION.cff did not match the actual release date of v0.3.3, so I fixed this issue. (Unfortunately, bump2version does not automatically enter the correct release dates on call.) I saw the outdated release date when I cited this project in a documentation.

Furthermore, I removed .bumpversion.cfg from itself. The file will always update itself. This was something I did not knew when I originally suggested it in #5, I am sorry about that.

Bumps actions-rs/cargo from 1.0.1 to 1.0.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps actions-rs/toolchain from 1.0.6 to 1.0.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This Pull Request adds a new configuration file: .bumpversion.cfg. This file controls the behaviour of bump2version, a Python 3 CLI to automatically update all version numbers in the whole repository. It is self-maintaining, i.e. it will even update itself.

I also added a new recipe to the justfile: bump {{part}}. At the moment, this project is versioned according to the pattern major.minor.patch. Just pass one of those parts to the recipe bump and all your version numbers will be updated automatically. (Release dates are not supported by bump2version.)

You now just need to call, for instance, just bump patch for updating immediately from 0.3.2 to 0.3.3 in all files. The CFF release date needs to be updated by hand as well as the CHANGELOG which also still needs to be specified manually. Furthermore, the tool will complain if there are uncommitted changes. Use bump2version <part> --allow-dirty to override this behaviour once.

bump2version is free and open source, it is licensed MIT and maintained here: https://github.com/c4urself/bump2version.

This Pull Request adjusts the URLs specified in the CITATION.cff. It now contains information regarding the documentation website (configured to be the main website) as well as the library description on crates.io (configured to be the place with final state artifacts).

By the way, I found a tool which makes adjusting the version information in the configuration files easier. It is named bump2version and is written in Python 3. For integration, one just needs to define a plain text configuration file to be stored in the repository root. I tried to set it up for this project but there are still some open points; automatically adjusting the release dates does not seem to be possible, for instance, and the changelog cannot be updated due to the URL being stored as a magic number. Shall I submit the recent progress in a separate Pull Request anyway, @sorairolake? The automatism is integrated into the justfile and just two files are left for update by hand.

Hi, @sorairolake,

When I explored the code base, I noticed that the linter did not totally agree on the source file example/cat.rs. This change fixes the linter warning properly.