james.maesandClaude Fable 5.1
1cdd06098d
Prepare, without cutting, the first artifact to be published from this
repository through the shared ci-workflows Maven workflow (push of
develop to release/0.1 publishes 0.1.0-RC.N to the Gitea Maven registry).
Add CHANGELOG.md, rewrite docs/RELEASE-STATUS.md with the publication
path, the first-RC steps, the dependency cohort and the relationship to
the GG Forge development pin 0.1.0-forge.162af9a7b8cd-archive1, and
update the README banner, Maven-publication section and known issues.
Carry the two Forge test-only PostgreSQL fixture patches verbatim
(FixtureEndpoint resolves the reachable container endpoint instead of
127.0.0.1; fixture health is reported after each intake case).
Recover the "-archive1" delta: the only class that differs between
Forge's 162af9a7b8 and 162af9a7b8cd-archive1 JARs is
ArchiveSecurity, whose digest guard now tolerates insert/update/delete
customizers and still refuses query/get/personalization customizers.
Express that in source with a focused ArchiveTest case.
Stop ignoring .gitea/ so the shared CI caller is tracked normally and
mark the retired platform-ci caller reference as superseded.
Verification: ./mvnw verify against Collaboration 53bd8f00 installed as
0.1.0-rf53bd8f00-SNAPSHOT: 284 tests, 0 failures, 0 errors, 58 skipped,
Checkstyle clean. Opt-in PostgreSQL/MySQL suites: 64 run, two
pre-existing failures (public QQQ 4.1.0-RC.21 lacks
QBackendTransaction.supportsRollbackCallbacks; the physical-drift probe
in PostgresRecordFilesTest), neither introduced here.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: James Maes <james@kof22.com>
6.7 KiB
Record Files — current status
Updated: 2026-11-06. Preparing the first published release candidate, 0.1.0-RC.1. Not a production 1.0; see KNOWN-ISSUES.md and TODO.md for the gates that remain.
Purpose
Retained uploads, scanned files and photo collections associated with QQQ records, with review status, permissions, immutable versions and audit history.
Repository layout
The root Maven module contains the QBit and its integration-test fixture classifier. Byte storage and attachment intake use the existing Collaboration attachment contracts. Generation and printing integrations live in their owning bridge modules, not here.
Building
Use Java 21 and the included Maven wrapper: ./mvnw verify. The PostgreSQL and MySQL integration suites are opt-in: they use Testcontainers (a Docker daemon is required) and run only with -DpostgresRecordFilesTests=true and -DmysqlRecordFilesTests=true; otherwise they are reported as skipped, so a plain verify is not provider evidence. The build needs a Collaboration artifact that carries the attachment lifecycle, upload journal and download SPI (AttachmentLifecyclePolicy, AttachmentDownload, AttachmentContentIntegrityException, uploadjournal.UploadRecoveryNavigation, security.ParentRecordAccess). Public Collaboration 0.1.0-RC.6 does not have them; that work is Collaboration PR 59. Until it is published, build against a locally installed snapshot of that branch and override the property, for example ./mvnw -Dqbit-collaboration.version=<local snapshot> verify.
Version and publication path
Versioning follows the shared KofTwentyTwo/ci-workflows Maven workflow, called from .gitea/workflows/build.yaml (PR 2). The version lives in the <revision> property of pom.xml and stays 0.1.0-SNAPSHOT on develop; the workflow computes published versions and commits the bump back.
| Ref | Version | Action |
|---|---|---|
feature branches, main |
unchanged | mvn verify only |
develop |
0.1.0-SNAPSHOT |
test, deploy snapshot |
release/0.1 |
0.1.0-RC.N |
test, deploy, commit bump, tag v0.1.0-RC.N |
tag v0.1.0 |
0.1.0 |
test, deploy, commit to main |
Packages go to the Gitea Maven registry, https://git.kof22.com/api/packages/QRun-IO/maven (sign-in required for reads as well as writes). Nothing is published to Maven Central and nothing is GPG-signed. GitHub is a shadow/archive; never publish from it.
First release candidate, step by step
- Merge Collaboration PR 59 and publish its release candidate (
release/0.1there), so the registry holds a Collaboration RC with the SPI above. - Merge PR 2 (shared CI caller) and this release-preparation PR into
develop; confirm thedeveloppush run passes and deploys0.1.0-SNAPSHOT. - Merge PR 1 (
quarantineCapturedFiles) intodevelop; it has no source conflict with this branch and only adds toRecordFilesQBitConfigandRetainedFileService. - On
develop, setqbit-collaboration.versionto the published Collaboration RC (a release candidate must not depend on a-SNAPSHOT), thengit push origin develop:release/0.1. The push run publishes0.1.0-RC.1and tagsv0.1.0-RC.1. - Resolve
com.kingsrook.qbits:qbit-record-files:0.1.0-RC.1(and itstestsclassifier if the fixture is wanted) from the registry in a fresh consumer cache and record the JAR and POM SHA-256 here. A passing build alone is not proof of publication.
The stable 0.1.0 comes later from a v0.1.0 tag on main; it is not part of this candidate.
What this candidate contains beyond the paused checkpoint (162af9a)
- The archive-capture customizer guard change that GG Forge ran as development pin
0.1.0-forge.162af9a7b8cd-archive1(mutation-only host customizers no longer refuse a capture; see CHANGELOG). - The two test-only PostgreSQL fixture patches from the Forge qualification (
FixtureEndpoint, fixture health reporting), unchanged fromscripts/local/patches/record-files-*.patchin the Forge handoff. - Release documentation. No behaviour other than the archive guard changed.
Relationship to the GG Forge development pin
Forge's pin 0.1.0-forge.162af9a7b8cd-archive1 was built from the same source as this candidate, but against development coordinates: qqq-backend-core 4.1.0-forge.33464d37e815-echo1, qqq-backend-module-rdbms 4.1.0-forge.33464d37e815 and qbit-collaboration 0.1.0-forge.8f348daf324d-files1. 0.1.0-RC.1 is a drop-in replacement for the Record Files code itself (same classes, plus the quarantineCapturedFiles setting once PR 1 is merged), but its POM pins the public QQQ 4.1.0-RC.21 tuple and the published Collaboration RC, so the host must move the whole cohort together, not only this coordinate.
Evidence retained
- Local
./mvnw -Dqbit-collaboration.version=0.1.0-rf53bd8f00-SNAPSHOT verifyon this branch (Collaboration commit53bd8f00, the commit PR 1 was verified against; Java 21): 284 tests, 0 failures, 0 errors, 58 skipped (the opt-in database suites), Checkstyle clean, BUILD SUCCESS. - Opt-in database suites with Docker 29.9.2 (
-DpostgresRecordFilesTests=true -DmysqlRecordFilesTests=true): 64 tests, 1 failure, 1 error. MySQL 15/15, PostgresTrackedDownload 3/3, PostgresRetainedUploadRecovery 5/5 and FixtureEndpoint 5/5 pass;POSTGRES_FIXTURE_HEALTHreportsrunning=true oom=false restarting=false endpointMatches=trueafter all 22 intake cases. The two failures pre-date this branch:PostgresIntakeAndRetentionTest.unmanagedTablesKeepOrdinaryAttachmentBehaviordies in Collaboration'sAttachmentsService.storeUploadwithNoSuchMethodError QBackendTransaction.supportsRollbackCallbacks()(the documented QQQ core after-rollback-callback gap: public 4.1.0-RC.21 lacks it, Forge builds against4.1.0-forge.33464d37e815-echo1), andPostgresRecordFilesTest.refusesLabelsAndPhysicalDriftfails itsisDurableBackendre-check afterALTER COLUMN at TYPE TIMESTAMPTZ(line 258), a physical-drift probe untouched by this change. - The earlier scanner integration proof used a private dependency cohort and does not constitute a standalone public release.
Source and release state
The starting source was extracted from Website-Backend commit b6fb23825a87412397dec703b9617148ae7eb601, then adapted for standalone packaging. This repository preserves the resulting source and existing licenses. The outstanding dependency order is Core, Collaboration, Scripting/Record Files, then the integrated Generation bridges and matching UI.
The old platform-ci caller is kept, inactive, as docs/release/qrun-release.reference.yaml; the shared ci-workflows caller supersedes it.