Skip to content

0.5.x-SelfUpdateReleaseWorkflow.md

Latest commit

 

History

History
60 lines (52 loc) · 3.74 KB

0.5.x-SelfUpdateReleaseWorkflow.md

File metadata and controls

60 lines (52 loc) · 3.74 KB
Raw

Self-update and release workflow (Feature Draft)

Status: Draft
Updated: 2026-05-20
Owner: Core
Purpose: Draft for self-updating aavion.studio, themes, plugin modules, manifests, development channels, and release packaging.

Overview

  • Defines how the CMS, themes, and plugin modules can be updated safely.
  • Covers .manifest files, git-based development channels, release packages, cleanup, and packaging automation.
  • Depends on plugin modules, backup/restore, setup automation, and security decisions.
  • Keeps update behavior explicit, reviewable, and recoverable before it modifies an installation.

Outline

The release and self-update workflow should allow aavion.studio, themes, and plugin modules to discover available updates, verify compatibility, review planned changes, and apply updates safely. The root .manifest already defines the basic update metadata shape: version, date, channel, and source.

Development channels may use git sources because they are useful during active development. Stable releases should support release packages once packaging rules, cleanup behavior, signatures/checksums, and rollback expectations are defined.

Self-update should not be implemented as an opaque automatic mutation. It should be an explicit operational workflow with preflight checks, backup recommendations or requirements, compatibility validation, and clear logs.

Technical Specifications

  • Use .manifest-style metadata for application, theme, and module update information.
  • Keep required application manifest keys aligned with the root .manifest:
    • APP_VERSION
    • APP_DATE
    • APP_NAME
    • APP_AUTHOR
    • APP_DESCRIPTION
    • APP_CHANNEL
    • APP_SOURCE
  • Extend manifests carefully for package type, compatibility, checksums, signatures, migration requirements, and dependencies.
  • Support dev-channel update discovery from configured git sources when appropriate.
  • Support stable-channel update discovery from release packages when packaging is defined.
  • Run compatibility checks before applying updates.
  • Check package compatibility before and after core updates.
  • Require backup or backup acknowledgement before destructive updates.
  • Validate package contents before replacing files.
  • Keep release packaging deterministic and exclude local-only files, caches, secrets, test artifacts when not needed, and development-only generated output.
  • Provide release dry-run output that lists included/excluded files.
  • Use Symfony Console commands for update and release workflows.
  • Log update checks, preflight failures, applied updates, migrations, and rollback attempts.
  • Keep rollback expectations explicit and conservative.

Testing & Validation

  • Test manifest parsing and compatibility checks.
  • Test update discovery for configured channels.
  • Test release packaging dry-runs.
  • Test package validation rejects missing required files and unsafe metadata.
  • Test update preflight blocks incompatible packages.
  • Test migration-required update paths in isolated environments.
  • Test rollback behavior once rollback is implemented.
  • Manually verify release packages before public distribution.

Implementation Notes

  • Decision proposed: Use git sources for development channels and release packages for stable channels.
  • Decision proposed: Require explicit preflight and backup acknowledgement before self-update applies changes.
  • Decision proposed: Keep release packaging deterministic and script-based.
  • Decision required: Decide package signature/checksum strategy.
  • Decision required: Decide whether self-update can modify the currently running installation directly or stages updates for administrator confirmation.
  • Decision required: Decide rollback scope before enabling automatic update apply.