Merge branch 'release/0.1.0'

* release/0.1.0:
  Bump version numbers to 0.1.0
  Describe current state in CHANGELOG
  add release tooling
  Initial CONTRIBUTING docs

CHANGELOG.md

+# Revision history for `ruffd`
+
+All notable changes are documented or linked to in this file. The format of the changelog is based on 
+['Keep a Changelog'](https://keepachangelog.com/en/1.0.0/). In short, this changelog is sorted the most recent
+release at the top, and the first section documents features that are in the `development` 
+branch but have not yet landed in the `main` branch from which releases are generated.
+
+`ruffd` adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html); with 
+the notable exception of custom mechanism support and excluding 
+bug-fixes there will not be any backwards-incompatible changes within a major version release.
+
+The MSRV (minimum supported Rust version) of the project is documented in the [`Cargo.toml`](Cargo.toml) and in the 
+[README](README.md). Changes to the MSRV are considered a **non-breaking change** and thus can happen in a *MINOR* 
+release. They will however *never* happen in a patch release.
+
+<!-- next-header -->
+# [Upcoming Changes] — Not Yet ;)
+
+[Changes rendered on GitHub][Upcoming/diff]
+
+
+# [v0.1.0] — 2023-01-28
+
+[Changes rendered on GitLab][v0.1.0/diff]
+
+## Added
+- Released `ruffd` on an unsuspecting world.
+- Initial functionality of logging in and viewing user entries.
+
+[Upcoming Changes]: https://git.paranoidlabs.org/plabs/ruffd/-/tree/development
+<!-- next-url -->
+[Upcoming/diff]: https://git.paranoidlabs.org/plabs/ruffd/-/compare/v0.1.0...development
+[v0.1.0]: https://git.paranoidlabs.org/plabs/ruffd/-/tags/v0.1.0
+[v0.1.0/diff]: https://git.paranoidlabs.org/plabs/ruffd/-/compare/v0.0.0...v0.1.0
+[v0.0.0]: https://git.paranoidlabs.org/plabs/ruffd/-/tags/v0.0.0
\ No newline at end of file

CONTRIBUTING.md

 # Contributing
+
+
+# Git workflow
+
+`ruffd` uses a merge-oriented branching model with a stable versioned `main` branch and a moving `development`, closely following [Vincent Driessen's branching model](https://nvie.com/posts/a-successful-git-branching-model/).
+This means that features are introduced into the moving `development` branch using merges, with the `development` branch being merged into the `main` branch to create tagged releases.
+
+I recommend installing either [\[link:\]`git-town`](https://www.git-town.com) or [\[link:\]`gitflow-avh`](https://github.com/petervanderdoes/gitflow-avh), as that tooling makes working within this branching model much easier.
+
+## Tooling setup
+
+### git-town
+
+1. Run `git town config setup` and select the appropiate,
+2. `git town new-branch-push-flag true` to automatically push feature branches when you create them
+3. `git-town pull-branch-strategy rebase`
+
+— or —
+
+1. `git town main-branch development` to set the branch to base feature branches off of
+2. `git town perennial-branches update` & enable `main` with spacebar
+3. `git town new-branch-push-flag true` to automatically push feature branches when you create them
+4. `git-town pull-branch-strategy rebase`
+
+Optionally, enable integration with our GitLab: 
+1. `git config git-town.gitlab-token <Plabs GitLab access token>`
+2. `git config git-town.code-hosting-driver gitlab`
+
+The GitLab access token can be used to have git-town open merge requests on your behalf. Thus it needs to have read&write access on the repository and API.
+
+**Note:** you can enable an 'offline' mode for `git-town` using `git town offline true` which will override any automatic pushing or pulling git town would otherwise do. Very useful for development on trains with only german mobile internet available.
+
+### gitflow-avh
+
+1. `git flow init -p 'feature/' -b 'bugfix/' -r 'release/' -x 'hotfix/' -s 'support/' -t 'v' -d`
+2. `git config --local gitflow.branch.master main`
+3. `git config --local gitflow.branch.develop development`
+
+## Workflows!
+
+### The usual feature development workflow:
+
+1. Start a new feature branch named "feature/<sensible name>" from the `development` branch. It often makes sense to have the sensible name being with your username (so have a branch named e.g. `feature/dequbed-foobarblorp`) but that is not a requirement.
+
+   (git cmd: `git town hack feature/<sensible name>` or `git flow feature start <sensible name>` or `git switch -c feature/<sensible name> development`)
+2. Work on the feature branch, commiting new code and pushing as your see fit.
+3. Rebase your feature branch on top of changes that happened to the development branch, or merge them in as you see fit.
+
+   (git cmd: `git town sync` or `git rebase development` with a `git pull` beforehand)
+4. When you're happy, `push` or `sync` your feature branch to the GL and open a merge request. `git-town` can automate this using `git town new-pull-request` which also automatically syncs beforehand.
+
+### Release workflow
+
+The below workflow uses `gitflow-avh` and [crateci's `cargo-release`](https://github.com/crate-ci/cargo-release).
+The latter can be installed using cargo: `cargo install cargo-release`.
+
+1. Make sure you have the required git-hook installed and marked executable. The release process specifically requires the file [tools/pre-release.sh]() to be installed as `.git/hooks/pre-release.sh`.
+2. `cargo release [level]` where `level` defines what version number to bump to and is [further described in the cargo-release reference](https://github.com/crate-ci/cargo-release/blob/master/docs/reference.md#bump-level).
+   - This will perform a *dry-run* and not make or commit any changes. Use it to verify that everything will happen as intended.
+3. `cargo release -x [level]` to perform the release. This will drop you on a new `release/[new version]` branch with changes to the Cargo.toml and CHANGELOG.md already added to be committed.
+   1. Verify everything that needs to be included for the release is included.
+   2. Run any pre-release tests and checks
+   3. Either finalize the release with `git flow release finish`. This will merge all branches as required and drop you into an editor to finalize the tag name and description.
\ No newline at end of file

release.toml

+publish = false
+push = false
+tag = false
+pre-release-hook = ["./.git/hooks/pre-release.sh", "{{version}}"]
+pre-release-commit-message = "Bump version numbers to {{version}}"
+
+[[pre-release-replacements]]
+file = "CHANGELOG.md"
+search = "\\[Upcoming Changes\\] — Not Yet ;\\)"
+replace = "[v{{version}}] — {{date}}"
+exactly = 1
+prerelease = true
+
+[[pre-release-replacements]]
+file = "CHANGELOG.md"
+search = "\\.\\.\\.development"
+replace = "...v{{version}}"
+exactly = 1
+prerelease = true
+
+[[pre-release-replacements]]
+file = "CHANGELOG.md"
+search = "Upcoming/diff"
+replace = "v{{version}}/diff"
+prerelease = true
+
+[[pre-release-replacements]]
+file = "CHANGELOG.md"
+search = "<!-- next-header -->"
+replace = """<!-- next-header -->
+# [Upcoming Changes] — Not Yet ;)
+
+[Changes rendered on GitHub][Upcoming/diff]
+
+"""
+exactly = 1
+prerelease = true
+
+[[pre-release-replacements]]
+file = "CHANGELOG.md"
+search = "<!-- next-url -->"
+replace = """<!-- next-url -->
+[Upcoming/diff]: https://git.paranoidlabs.org/plabs/ruffd/-/compare/v{{version}}...development
+[v{{version}}]: https://git.paranoidlabs.org/plabs/ruffd/-/tags/v{{version}}"""
+exactly = 1
+prerelease = true

tools/pre-release.sh

+#!/usr/bin/env bash
+
+if [[ ${DRY_RUN} == "true" ]];
+then
+    echo "=====================================--------==="
+    echo "DRY_RUN SET, ONLY PRINTING THE PLANNED ACTIONS!!"
+    echo "=====================================--------==="
+    echo "-- COMMAND LIST START --"
+    echo git stash
+    echo git flow release start $@
+    echo git stash pop
+    echo git add Cargo.toml CHANGELOG.md
+    echo "-- COMMAND LIST END --"
+else
+    git stash
+    git flow release start $@
+    git stash pop
+    git add Cargo.toml CHANGELOG.md
+fi