Update README.md

.github/workflows/d.yml

@@ -0,0 +1,32 @@
+# This workflow uses actions that are not certified by GitHub.
+# They are provided by a third-party and are governed by
+# separate terms of service, privacy policy, and support
+# documentation.
+name: D
+
+on:
+  push:
+    branches: [ "master" ]
+  pull_request:
+    branches: [ "master" ]
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v3
+    - uses: dlang-community/setup-dlang@4c99aa991ce7d19dd3064de0a4f2f6b2f152e2d7
+
+    - name: 'Build & Test'
+      run: |
+        # Build the project, with its main file included, without unittests
+        dub build --compiler=$DC
+        # Build and run tests, as defined by `unittest` configuration
+        # In this mode, `mainSourceFile` is excluded and `version (unittest)` are included
+        # See https://dub.pm/package-format-json.html#configurations
+        dub test --compiler=$DC

README.md

@@ -7,12 +7,14 @@ Eventy
 
 ---
 
+[![D](https://github.com/deavmi/eventy/actions/workflows/d.yml/badge.svg)](https://github.com/deavmi/eventy/actions/workflows/d.yml)
+
 ## Getting started
 
 ### The _engine_
 
 The first thing every Eventy-based application will need is an instance of the `Engine`.
-This provides the user with a single object instance of the [`Engine` class](https://eventy.dpldocs.info/v0.4.1/eventy.engine.Engine.html) by which
+This provides the user with a single object instance of the [`Engine` class](https://eventy.dpldocs.info/v0.4.3/eventy.engine.Engine.html) by which
 the user can register _event types_, _signal handlers_ for said events and the ability
 to trigger or _push_ events into the engine.
 
@@ -45,7 +47,7 @@ This will tell the engine to create two new event types with tags `1` and `2` re
 We're almost done. So far we have created a new _engine_ for handling our event tyoes and
 the triggering of events. What is missing is something to _handle those event types_ when
 an event of one of those types is pushed into the engine. Such handlers are referred to as
-_signal handlers_ and in Eventy these are instances of the [`Signal` class](https://eventy.dpldocs.info/v0.4.1/eventy.signal.Signal.html).
+_signal handlers_ and in Eventy these are instances of the [`Signal` class](https://eventy.dpldocs.info/v0.4.3/eventy.signal.Signal.html).
 
 We're going to create a signal that can handle both of the event types `1` and `2` that we
 registered earlier on. We can do this by creating a class that inherits from the `Signal`
@@ -143,12 +145,12 @@ the other.
 
 ## Release notes
 
-### `v0.4.0`
+### `v0.4.3`
 
 ```
-Completely overhauled Eventy system for the v0.4.0 release
+Completely overhauled Eventy system for the v0.4.3 release
 
 Removed the event-loop for a better system (for now) whereby we just dispatch signal handlers on the call to `push(Event)`.
 
 In a future release I hope to bring the event loop back but in a signal-based manner, such that we can support deferred events and priorities and such
-```
+```