Merge pull request #11 from naviqore/feature/NAV-8-documentation

Writerside/cfg/buildprofiles.xml

@@ -5,8 +5,15 @@
     <variables/>
     <build-profile instance="d">
         <variables>
+            <custom-favicons>favicon/favicon.ico</custom-favicons>
+            <header-logo>favicon/android-chrome-512x512.png</header-logo>
             <noindex-content>true</noindex-content>
         </variables>
     </build-profile>
+    <build-profile instance="n">
+        <variables>
+            <noindex-content>false</noindex-content>
+        </variables>
+    </build-profile>
 
 </buildprofiles>

Writerside/cfg/favicon/site.webmanifest

@@ -0,0 +1 @@
+{"name":"","short_name":"","icons":[{"src":"/android-chrome-192x192.png","sizes":"192x192","type":"image/png"},{"src":"/android-chrome-512x512.png","sizes":"512x512","type":"image/png"}],"theme_color":"#ffffff","background_color":"#ffffff","display":"standalone"}

Writerside/d.tree

@@ -3,7 +3,7 @@
         SYSTEM "https://resources.jetbrains.com/writerside/1.0/product-profile.dtd">
 
 <instance-profile id="d"
-                 name="Documentation"
+                 name="Naviqore"
                  start-page="introduction.md">
 
     <toc-element topic="introduction.md"/>
@@ -31,5 +31,6 @@
     <toc-element topic="implementation.md">
         <toc-element topic="git-best-practices.md"/>
         <toc-element topic="code-style-guide.md"/>
+        <toc-element topic="release.md"/>
     </toc-element>
 </instance-profile>

Writerside/topics/code-style-guide.md

@@ -98,11 +98,17 @@ Further:
 
 ```Python
 class ExampleService:
-MAX_ATTEMPTS = 5
+
+
+    MAX_ATTEMPTS = 5
+
 
 def __init__(self, repository):
-self._repository = repository
+
+
+    self._repository = repository
+
 
 def find_by_id(self, id: str) -> Optional[Example]:
-        return self._repository.find_by_id(id)
+    return self._repository.find_by_id(id)
 ```

Writerside/topics/implementation.md

@@ -2,3 +2,4 @@
 
 - [Git Best Practices](git-best-practices.md)
 - [Code Style Guide](code-style-guide.md)
+- [Release](release.md)

Writerside/topics/introduction.md

@@ -70,8 +70,6 @@ The components will be made available under a permissive or copyleft open-source
 
 ## Initial situation
 
-## Background
-
 The existing literature highlights several complexities associated with transit routing:
 
 1. **Network Complexity**: Public transit networks are intricate, with multiple routes, stops, footpaths and

Writerside/topics/methodology.md

@@ -2,10 +2,9 @@
 
 ## Software Development Process
 
-The development process follows an iterative Scrum-like setup with 4-week sprints between supervisor meetings. Task management and
-monitoring
-are facilitated using the agile project tracking software, Jira. This structured way of working enables team members to
-work independently.
+The development process follows an iterative Scrum-like setup with 4-week sprints between supervisor meetings. Task
+management and monitoring are facilitated using the agile project tracking software, Jira. This structured way of
+working enables team members to work independently.
 
 Key aspects of the process include:
 
@@ -51,13 +50,6 @@ identification and resolution of issues, ensuring a more efficient development p
 Clean code principles are followed, and all code is reviewed by team members. For more details, refer to
 the [Code Style Section](requirements.md).
 
-This project adheres to [Semantic Versioning](https://semver.org/). We use a three-part version numbering system:
-MAJOR.MINOR.PATCH. Here is what each part represents:
-
-- **MAJOR version** when we make incompatible API changes,
-- **MINOR version** when we add functionality in a backwards compatible manner, and
-- **PATCH version** when we make backwards compatible bug fixes.
-
 ## Documentation
 
 Documentation is continuously written in WriterSide and is published daily on GitHub Pages. The primary language for

Writerside/topics/release.md

@@ -0,0 +1,35 @@
+# Release
+
+## Semantic Versioning
+
+This project adheres to [Semantic Versioning](https://semver.org/). We use a three-part version numbering system:
+`MAJOR.MINOR.PATCH`. Here is what each part represents:
+
+- **MAJOR version** when we make incompatible API changes,
+- **MINOR version** when we add functionality in a backwards compatible manner, and
+- **PATCH version** when we make backwards compatible bug fixes.
+
+Version tags are prefixed with a `v`, e.g., `v3.1.4`.
+
+## Release Process
+
+To ensure a smooth and consistent release process, follow these steps:
+
+1. **Release branch:**
+   Create a new release branch from `main` with the semantic version number to be
+   published: `git checkout -b release/vX.X.X`
+
+2. **Version and documentation:**
+   Set the correct version number in the version file (`pom.xml`, `CMakeLists.txt`, `package.json` `poetry.toml`, ...).
+   Update any other necessary documentation.
+
+3. **Pull request:**
+   Submit a pull request with the new version number and documentation changes. Include a release description to be used
+   later in the release. Since we are generating the changelog automatically, keep it concise and mention the most
+   important aspects.
+
+4. **Publish:**
+   Upon review and merging of the pull request, use the GitHub web interface to create a new release
+   named `<REPOSITORY-NAME> <X.X.X>` (e.g., `public-transit-service 0.2.1`). Set the version tag as `vX.X.X` and
+   automatically generate the changelog for the release. Add the release description from the PR comment and hit
+   publish, which triggers the appropriate GitHub actions (e.g., Maven or Docker Publish).