Repository files, collaboration, releases and project activity.
ArchForge 11.3.8 · Desktop 1.5.5 · External Status 1.0.8
Purpose
This is a visible terminology and branding update, not a replacement for the Git engine. Public websites and the Desktop UI use ArchForge branding. The system still uses real git commands, Git protocols, .git directories, .gitignore files, commit references, and existing internal service IDs. Existing .archforge clone URLs remain canonical, and this release does not change the configured legacy .git transport policy. No repository or database migration is needed.
1. Back up the main website
Back up the current website tree, .env, MySQL, bare repositories under data/, Desktop release assets, and any persistent uploads before deployment. Keep the current release available for rollback.
Apply ArchForge-v11.3.8-UPDATE-FROM-11.3.7.zip over an existing ArchForge 11.3.7 source tree or deploy the full website ZIP. Restart the Node.js server using your normal hosting control panel. Do not replace .env, database files, live repository storage or other runtime state.
Legal notices
Branding changes in legal/drafts/ are unpublished drafts. Already published policies stored in MySQL are not automatically rewritten. Review all legal changes and republish through the Legal Center only after confirming their accuracy and required approvals. Historical incident descriptions and user-created text in the database are intentionally not rewritten.
The website now publishes https://archforge.nl/desktop/releases/latest.json for Desktop 1.5.5 with an exact downloadable ZIP and SHA-256. Make sure this endpoint is reachable without login or redirect. The release ZIP is included with both the full website project and the update.
2. ArchForge Desktop 1.5.5 — Arch Linux / KDE
Extract ArchForge-Desktop-v1.5.5-FULL.zip and, as your normal desktop user, run:
chmod +x install.sh
./install.sh
The ZIP contains the properly built packaging/archforge-desktop-1.5.5.tar.gz; do not install as root. You can also apply ArchForge-Desktop-v1.5.5-UPDATE-FROM-1.5.4.zip over the 1.5.4 source checkout; after applying it, run ./install.sh normally.
The Desktop UI, first-run wizard, menu entries and user-visible error copy are rebranded. The Git binary dependency remains mandatory, because it is how ArchForge implements version control. Local .git directories, credentials, KDE Wallet and repository locations are untouched. All previously migrated .archforge URLs continue to work.
3. External Status 1.0.8 — Debian 13
Commit and push the full project or apply ArchForge-External-Status-v1.0.8-UPDATE-FROM-1.0.7.zip to the existing Git repository, then on Debian 13:
cd ~/archforge-external-status
git pull --ff-only
sudo bash scripts/deploy.sh "$PWD"
git pull uses your existing Git checkout; the command name is intentionally unchanged. If the checkout is owned by a non-root user, pull as that user. The deploy step runs as root after you have reviewed the checked-out source. Deployment backs up the existing SQLite database and previous app release, executes its tests and restarts the status service with rollback on launch failure.
Do not rerun install.sh and do not erase /var/lib/archforge-status/status.db or /etc/archforge-status/status.env. No changes to Caddy/DNS/SSL are needed. Current uptime samples, incidents, administrator credentials and confirmation tokens remain intact. Service names are updated automatically in the existing SQLite services table at service initialization, without resetting history.
4. Validation
- Website navigation, repository pages, maintenance notices, security pages and status center: ArchForge branding.
- Desktop menu, project inspector, setup wizard and alerts: ArchForge branding.
- Independent status public and admin screens: ArchForge HTTPS and ArchForge SSH.
- Browser repository code examples still contain real
git clone,git pushetc. These are required external command names, not product labels. - Website Git Smart HTTP/SSH and existing transport authentication, hooks and permission checks are unchanged.
.gitdirectories and internalgit_*database keys remain unchanged to prevent breaking existing data.
The archives are source releases; you must still verify the services on your live hosts and check that all user-generated content and previously published policies are correct.