server/docs/maintainers/release.md

Rama main · réplica de lectura del repositorio original.

# Release ArtLight

ArtLight releases are built from an existing, v-less semantic-version tag such as `1.19.0-beta.4`
or `1.19.0`. The tagged commit must contain the matching version-scoped release notes file, for
example `release_notes/1.19.0-beta.4.md`.

Linux release candidates live on `vibe-test`. Every push to that branch builds and validates the
installable Arch/CachyOS package without creating a GitHub Release, updating the signed pacman
repository, or deploying the production Pages site. Download the `build-Archlinux` artifact from
the successful CI run for installation and MOK testing. Promote the verified commit to `master`
before creating the first production tag.

## Prepare the release

1. Update and review the matching file under `release_notes/`.
2. Run the complete local build and test suite appropriate for the changed platforms.
3. Confirm the worktree is clean and the intended release commit is pushed.
4. Create and push the v-less tag:

   ```bash
   git tag 1.19.0-beta.4
   git push origin 1.19.0-beta.4
   ```

Do not create a second `v1.19.0-beta.4` tag. The release workflow adds the `v` prefix only to the
display title.

## Build and publish

The tag push runs `.github/workflows/ci.yml`. The release gate validates the tag, exact release
notes, and source commit, then builds the retained release artifacts. Successful release artifacts
are retained for 14 days.

After the tag build succeeds:

1. Open the **Sign and publish release** workflow.
2. Enter the exact v-less `release_tag`.
3. Leave the recovery run IDs empty during a normal release.
4. Enable `release_draft` for the first production releases so every asset can be inspected before
   publication.
5. Run the workflow and approve the external Windows signing request when required.

The workflow verifies that the retained artifacts came from the exact tagged commit. It publishes
the GitHub Release against the existing tag and includes the Arch package generated by that CI run.

## Verify the published release

- Confirm the GitHub Release is attached to the v-less source tag.
- Confirm its stable/pre-release classification matches the tag suffix.
- Confirm the release notes and every asset version match the tag.
- Download the Arch package on a clean Arch or CachyOS test machine and verify installation,
  executable capabilities, DKMS status, module signature, and managed-display startup.
- Verify the Windows signatures and installer provenance before publishing a draft.

## Publish the Arch Linux repository

For a non-draft release, run **Publish signed Arch repository** with the exact v-less
`release_tag`. The workflow downloads the release's single validated `artlight` package, checks
its embedded package name, version, and architecture, signs it, updates the signed `artlight`
database on the `arch-repo` branch, and pushes that branch. The Pages workflow then deploys it at
`https://onaiaku.github.io/ArtLight/arch/x86_64`.

The `arch-repository` GitHub environment must contain:

- Environment secret `ARCH_REPO_GPG_PRIVATE_KEY`: the ASCII-armored private repository-signing key.
- Environment secret `ARCH_REPO_GPG_PASSPHRASE`: the private key's strong passphrase.
- Environment variable `ARCH_REPO_GPG_FINGERPRINT`: the full uppercase fingerprint with no spaces.

Protect the `arch-repository` environment with required-reviewer approval. Keep an offline backup
of the private key and its revocation certificate. Do not use a personal day-to-day signing key or
the Secure Boot/MOK module-signing key for this repository.

After publication, verify that the Pages deployment succeeds, import the published public key on a
clean Arch or CachyOS machine, add the `[artlight]` repository shown on the project site, and run
`pacman -Syu artlight`. A normal system upgrade must subsequently discover ArtLight updates.