ci(windows): use native PowerShell git checkout to eliminate Node.js dependency on Windows runner

.gitea/workflows/release.yml

@@ -7,9 +7,9 @@ on:
   workflow_dispatch:
     inputs:
       tag:
-        description: 'Release tag to publish assets to (default: v2.0.0)'
+        description: 'Release tag to publish assets to (default: v2.0.1)'
         required: false
-        default: 'v2.0.0'
+        default: 'v2.0.1'
 
 jobs:
   release-linux:
@@ -47,13 +47,22 @@ jobs:
     runs-on: windows-latest
     steps:
       - name: Checkout Repository
-        uses: actions/checkout@v4
+        shell: powershell
+        run: |
+          $server = "${{ github.server_url }}"
+          $token = "${{ secrets.TAG_TOKEN || github.token }}"
+          $repo = "${{ github.repository }}"
+          $cleanUrl = $server -replace "^https?://", ""
+          $authUrl = "https://${token}@${cleanUrl}/${repo}.git"
 
-      - name: Setup Python
+          if (-not (Test-Path ".git")) {
-        uses: actions/setup-python@v5
+            git init
-        with:
+            git remote add origin $authUrl
-          python-version: '3.12'
+          } else {
-        continue-on-error: true
+            git remote set-url origin $authUrl
+          }
+          git fetch --depth 1 origin "${{ github.sha }}"
+          git checkout -f FETCH_HEAD
 
       - name: Install Dependencies
         shell: powershell

README.md

@@ -372,8 +372,8 @@ Releases can be built and published through three complementary channels:
 ### 1. Tag Push Automation (Gitea Actions)
 Pushing a release tag automatically triggers the build workflows:
 ```bash
-git tag v2.0.0
+git tag v2.0.1
-git push origin v2.0.0
+git push origin v2.0.1
 ```
 The consolidated workflow **`release.yml`** defines two parallel jobs:
 - **`release-linux`** (`ubuntu-latest`): Compiles standalone native ELF binaries (`Linux_Client.bin`, `Server.bin`) and checksums.
@@ -382,7 +382,7 @@ The consolidated workflow **`release.yml`** defines two parallel jobs:
 ### 2. Manual Workflow Dispatch (Gitea UI)
 Workflows can be manually triggered on demand from the Gitea web interface:
 1. Navigate to **Actions** $\rightarrow$ **Release Binaries & Installers** (`release.yml`).
-2. Click **Run workflow**, set the release tag (defaults to `v2.0.0`), and run.
+2. Click **Run workflow**, set the release tag (defaults to `v2.0.1`), and run.
 
 ### 3. Native Local Windows Build & Direct Release Upload
 For environments without a registered Windows CI runner, Windows executables can be built and published directly to Gitea releases:
@@ -391,5 +391,5 @@ For environments without a registered Windows CI runner, Windows executables can
 python compilation/package_dist.py --target windows
 
 # 2. Upload assets and release notes directly to the Gitea release
-python compilation/upload_release.py --tag v2.0.0 --token <GITEA_TOKEN> --skip-build
+python compilation/upload_release.py --tag v2.0.1 --token <GITEA_TOKEN> --skip-build
 ```

RELEASE_NOTES.md

@@ -1,3 +1,25 @@
+# LOGAR Release v2.0.1
+
+Maintenance and deployment release consolidating Gitea Actions release automation into a unified single workflow file, standardizing release dispatching across platforms, and bumping version definitions across server hub and Windows installers.
+
+### Key Highlights & Changes in v2.0.1:
+
+- **Consolidated Single Release Automation Workflow (`.gitea/workflows/release.yml`)**:
+  - Unified separate platform release files into a single, cohesive workflow (`release.yml`) running parallel jobs (`release-linux` on `ubuntu-latest` and `release-windows` on `windows-latest`).
+  - Standardized tag matching for Gitea Actions on `push: tags: ['v*']`.
+  - Added streamlined manual `workflow_dispatch` triggers with automated release tag defaulting (`v2.0.1`).
+  - Retired deprecated `release-linux.yml` and `release-windows.yml` files.
+
+- **Installer & Engine Version Bump**:
+  - Updated FastAPI Hub engine version to `2.0.1` in `src/Server.py`.
+  - Bumped Inno Setup Windows Client Installer (`compilation/installer_client.iss`) `AppVersion` to `2.0.1`.
+  - Bumped Inno Setup Windows Server Installer (`compilation/installer_server.iss`) `AppVersion` to `2.0.1`.
+
+- **Distribution & Release Documentation**:
+  - Updated root and distribution documentation across all 5 deployment targets to reflect the 25 passing unit tests and tripartite release options.
+
+---
+
 # LOGAR Release v2.0.0
 
 Major architectural release introducing Mutual TLS 1.3 (mTLS) transport security, built-in dynamic PKI & license accounting, in-flight certificate validity monitoring and auto-renewal, and automated Windows and Linux service installers.

compilation/installer_client.iss

@@ -1,6 +1,6 @@
 [Setup]
 AppName=LOGAR Client
-AppVersion=2.0.0
+AppVersion=2.0.1
 DefaultDirName={autopf}\LOGAR
 OutputDir=..\dist
 OutputBaseFilename=LOGAR-Client-Setup

compilation/installer_server.iss

@@ -1,6 +1,6 @@
 [Setup]
 AppName=LOGAR Server
-AppVersion=2.0.0
+AppVersion=2.0.1
 DefaultDirName={autopf}\LOGAR-Server
 OutputDir=..\dist
 OutputBaseFilename=LOGAR-Server-Setup

src/Server.py

@@ -38,7 +38,7 @@ DEFAULT_DB_FILE = "logar_state.db"
 EVALUATION_WINDOW_HOURS = 12
 RUN_THRESHOLD = 4
 
-app = FastAPI(title="LOGAR Cloud Ingestion & Hermes Hub", version="2.0.0")
+app = FastAPI(title="LOGAR Cloud Ingestion & Hermes Hub", version="2.0.1")
 
 # Global context holding server state
 SERVER_STATE: Dict[str, Any] = {}