Task/remove unnecessary constructs

.github/workflows/testing.yml

@@ -2,9 +2,9 @@ name: 'Unit Tests & Static Analysis'
 
 on:
   push:
-    branches: [ release-1.x, release-2.x ]
+    branches: [ release-1.x, release-2.x, release-3.x ]
   pull_request:
-    branches: [ release-1.x, release-2.x ]
+    branches: [ release-1.x, release-2.x, release-3.x ]
 
 jobs:
   continuous-integration:

.gitignore

@@ -1,4 +1,5 @@
 .phpunit.cache
 .phpunit.result.cache
 architectural-decisions.xml.bak
+composer.lock
 vendor/

README.md

@@ -58,41 +58,8 @@ final class MyFirstDecision extends DocBlockArchitecturalDecision {
 }
 ```
 
-Optionally, you can also annotate appropriate places in your codebase where it might make sense to do so. After that you can run a command to generate an XML document detailing all of your decisions and where they were annotated in your codebase.
-
-```shell
-./vendor/bin/architectural-decisions
-```
-
-If successful a file named `architectural-decisions.xml` will be generated and stored in the root of your project. You can use this file to generate views into the content, assist in static analysis, or whatever else you might want to do with the ADR information and where it is used in your codebase.
+Optionally, you can also annotate appropriate places in your codebase where it might make sense to do so.
 
 ### Setting Custom Meta Data
 
 There might be additional information you'd like to include with an ArchitecturalDecisionRecord that doesn't fit into the contents of the decision. Perhaps it is additional data that can be used with static analysis. Perhaps you like to include information about who authored the decision or some other meta-data. You can implement the `ArchitecturalDecisionRecord::setMetaData(DOMElement $meta)` method to add whatever data you'd like to the generated XML document. Please review the [DOMDocument](https://www.php.net/domdocument) documentation for how to appropriately add elements and attribute to the `<meta>` element.
-
-## Example XML Document
-
-This document was generated by parsing this library. We include a lightweight example for why you should use Attributes for ADR!
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<architecturalDecisions xmlns="https://architectural-decision.cspray.io/schema/architectural-decision.xsd">
-
-  <architecturalDecision 
-      id="UsingAttributesForArchitecturalDecisions"
-      attribute="Cspray\ArchitecturalDecision\ArchitecturalDecisionRecords\UsingAttributesForArchitecturalDecisions">
-    <date>2022-07-19</date>
-    <status>Accepted</status>
-    <contents><![CDATA[Architectural Decision Records (ADR) can be useful in determining why a piece of software is the way it is. While these type of documents can live anywhere, an Attribute in your codebase can be a good place to store this info. For more information, please check out the README in this repo or at https://github.com/cspray/architectural-decision]]></contents>
-    <codeAnnotations>
-      <codeAnnotation>
-        <class>Cspray\ArchitecturalDecision\ArchitecturalDecisionRecord</class>
-      </codeAnnotation>
-    </codeAnnotations>
-    <meta />
-  </architecturalDecision>
-
-  <!-- Additional architecturalDecision would be listed here -->
-
-</architecturalDecisions>
-```