Skip to content

Release checklist

Use this checklist for each Pixie Dark release. A production deployment and a Drupal.org release are separate operations and require separate verification.

Code and package

  • [ ] Review docs/backlog.md and resolve every release blocker.
  • [ ] Run composer install, composer validate --strict, composer lint:php, and composer phpcs.
  • [ ] Run php tests/check-yaml.php and git diff --check.
  • [ ] Commit to the Issue-fork branch and run bash tests/check-package.sh. It checks the committed git archive, its required runtime files and size. Uncommitted files are not tested by this archive check.
  • [ ] Confirm the archive excludes CI files, local settings, secrets, and machine-specific files. .gitattributes also excludes the test harness, PHPCS rules and MkDocs build configuration; runtime assets, documentation, licenses, and the complete starterkit recipe remain packaged.
  • [ ] Confirm every bundled third-party asset is documented in docs/assets.md.

Drupal compatibility

  • [ ] Install the archive on a clean supported Drupal 10.6 site.
  • [ ] Install the archive on a clean Drupal 11.4 site.
  • [ ] Verify front page, inner page, login page, theme settings, every region, and optional footer blocks, both with and without copyright_footer.
  • [ ] Verify uninstall and reinstall.

The drupal-rendered-navigation matrix pins the supported minor lines to ~10.6.0 and ~11.4.0, installs the committed archive, and checks both optional footer states and theme reinstall. Its artifacts record the resolved core version and source SHA. A green job for one core line does not cover the other. See integration tests in the source checkout for the automated cases; the test harness is not part of the distributed theme.

Visual and accessibility checks

  • [ ] Compare all four variants and Pixie Example at desktop, tablet, and mobile widths.
  • [ ] Check keyboard order, focus visibility, skip link, landmarks, headings, contrast, and reduced motion.
  • [ ] Inspect screenshot.png at its actual Drupal Appearance-page size.

Publication

  • [ ] Review the release notes and version number.
  • [ ] Use the Drupal Issue fork as the MR source and the official development branch as its target. Never push implementation commits to that branch.
  • [ ] Confirm the exact MR head passes all validation jobs, complete independent review and approval, then merge through the approved MR workflow.
  • [ ] Verify the merged commit and its successful pipeline. Obtain final approval for the exact tag name, SHA, commit subject, and permitted tagging route. Do not infer release approval from implementation or merge approval.
  • [ ] Create the approved annotated Git tag and publish the reviewed release notes.
  • [ ] Install the published package once through Composer in a clean project.

Production rollout

  • [ ] Back up site configuration, database, and the currently deployed theme.
  • [ ] Deploy to a preview route or non-default theme first.
  • [ ] Verify anonymous and authenticated pages for every affected domain.
  • [ ] Switch the default theme only after visual and functional comparison.
  • [ ] Record the rollback path and retain the backup until verification ends.