[codeling]

Steps 1–3 of automating the package (release plan #250): pkg_bfstop is folded in here, the version is checked everywhere, and CI builds the package, installs it, and runs an update from the previous release with it. Merge together with codeling/com_bfstop#27, which is on the branch of the same name (deploy.sh reads its version from the manifest). codeling/pkg_bfstop#2 points that repo here; after that you can archive it.

Changes

package/ (moved from pkg_bfstop):

• pkg_bfstop.xml, script.php and update.xml.
• build.sh <com_bfstop checkout> [out]: zips the plugin and component with their own deploy.sh, working from copies so the checkouts aren't changed. It runs check-zip on all three zips and writes build/{bfstop,com_bfstop,pkg_bfstop}-<version>.zip plus a SHA256SUMS-<version> file. Nothing gets committed.
• README.md: how building and versions work.

One version number:

• tests/lint/check-versions.php checks that all the places the version is written agree: bfstop.xml of the plugin and the component, pkg_bfstop.xml, update.xml, and the first CHANGELOG entry. build.sh refuses to build if they don't.
• With --release=<tag> (for the release workflow, step 4) they must also equal the tag, and the CHANGELOG entry must carry its date. The CHANGELOG now says 2.0.0 (unreleased), and the release commit sets the date.
• deploy.sh reads the version from bfstop.xml and starts with a fresh zip instead of adding to an old one.

CI (ci.yml):

• Package job: builds once and uploads bfstop-<version> as a run artifact. You can download it and try it out.

• Integration matrix: installs that package zip through Joomla's installer (install-joomla.sh with BFSTOP_PACKAGE), instead of zips of the raw checkouts. Without BFSTOP_PACKAGE but with COM_BFSTOP_ROOT, it builds the package from the checkouts; that's the path com_bfstop's workflow uses.

• "Update from the previous release", on the Joomla 5 + MySQL/MariaDB matrix entries (tests/ci/upgrade-test.sh):

  1. Downloads pkg_bfstop-1.5.2.zip from the GitHub release, checked against the SHA-256 pinned in tests/ci/previous-release.sha256.
  2. Installs it and seeds 1.5-style settings and data (tests/Upgrade/fixtures/seed.php).
  3. Updates with the built package and runs the new upgrade suite, which checks:
     • versions and schema;
     • the blockMode migration, with the other settings kept;
     • utf8mb4 tables and seeded username statistics;
     • addresses canonicalized on the first request, with the blocks still answering 403;
     • an update interrupted halfway can be run again;
     • the package refuses an unsupported Joomla version and changes nothing.

  The suite is skipped in other runs. After each release, previous-release.sha256 gets the new release.

• Lint job: runs the version check.

• New actions, pinned to SHAs like the rest: actions/upload-artifact v7.0.2 and actions/download-artifact v8.0.2.

Tested locally

• package/build.sh builds all three zips without touching either checkout.
• Fresh Joomla 6.2.0 + PostgreSQL with BFSTOP_PACKAGE: 388 tests pass.
• Fresh Joomla 5.4.10 + MySQL, building from the checkouts: 388 tests pass.
• upgrade-test.sh on Joomla 5.4.10 + MySQL 8.4: 7/7 pass.
• Against deliberately broken builds, the right tests fail:
  • CAN FAIL markers removed → "update which stopped halfway" fails.
  • Package without its install script → "refuses unsupported Joomla" fails.
• Lint (workflows, versions, XML) and unit tests pass.

Next (steps 4–5)

• A release workflow: on tag X.Y.Z, run check-versions --release, build, run the same tests, and create a draft release with the zips and checksums.
• GitHub Pages for bfstop.bfroehler.info, serving update.xml and update-pkg.xml.

---

Generated by Claude Code