Files

93 lines
3.4 KiB
Markdown
Raw Permalink Normal View History

# Spec Delta
## ADDED Requirements
### Requirement: Pinned release selection
The installer SHALL accept a release tag and install that release instead of the
latest. Without a tag it SHALL install the latest release.
#### Scenario: A pinned release is installed
- **WHEN** the installer is invoked with a release tag
- **THEN** it fetches that tag's metadata and installs its bundle
#### Scenario: Default is the latest release
- **WHEN** the installer is invoked without a release tag
- **THEN** it installs the latest release
#### Scenario: Unknown pinned release
- **WHEN** the pinned tag does not exist
- **THEN** the installer exits with a failure message and installs nothing
### Requirement: Pinned release metadata endpoint
The app SHALL expose a same-origin endpoint that returns a specific release's
tag and asset names as same-origin URLs, with the same authentication, filtering
and non-disclosure guarantees as the latest-release endpoint. It SHALL reject a
tag that is not a valid release tag without contacting the forge.
#### Scenario: Tagged release is returned
- **WHEN** a client requests the metadata for an existing tag
- **THEN** the response carries that release's tag and its assets as same-origin
URLs
#### Scenario: Invalid tag is rejected
- **WHEN** a client requests metadata for a tag that is not a valid release tag
- **THEN** the app rejects the request without contacting the forge
### Requirement: Installed version is tracked and upgrades are reported
The installer SHALL treat the git hash in the bundle's asset name as the version.
It SHALL hand that version to the bundle installer, which SHALL record it beside
the installed binary and SHALL report an upgrade with the previous and new
versions on the next run. Uninstalling SHALL remove the recorded version.
#### Scenario: Version is derived from the asset name
- **WHEN** the installer selects a bundle named `fpagent-<hash>-<platform>.tar.gz`
- **THEN** it uses `<hash>` as the version
#### Scenario: Upgrade is reported
- **WHEN** the recorded version differs from the version being installed
- **THEN** the bundle installer reports the change from the old to the new
version
#### Scenario: First install records the version
- **WHEN** no version has been recorded yet
- **THEN** the bundle installer records the new version and reports no upgrade
#### Scenario: Uninstall removes the recorded version
- **WHEN** the installer is asked to uninstall
- **THEN** the recorded version is removed
### Requirement: A managed running service is restarted on upgrade
When the installer is asked to manage the systemd service and a service is
already running, the installer SHALL restart it after installing the new binary
so the new binary takes effect. A fresh install SHALL NOT perform a redundant
restart, and the installer SHALL NOT restart the service when service management
is not requested.
#### Scenario: Upgrade restarts the running service
- **WHEN** the running service is managed and a new binary is installed
- **THEN** the service is restarted on the new binary
#### Scenario: Fresh install starts the service
- **WHEN** the service is not running and service management is requested
- **THEN** the service is started and no separate restart is performed
#### Scenario: Service management not requested
- **WHEN** service management is not requested
- **THEN** the installer does not restart the service