A test report names build A, while the file prepared for release names build B. Both carry version 1.2.0. Match the exact artifact identity to the test evidence before treating a version label as sufficient. A software release checklist should connect source, artifact, verification, release notes, and the actual publication record.
Begin with your project's maintained release procedure. Record the intended version/tag, exact source revision, artifact reference, applicable test records, compatibility notes, release owner, and publication route. Keep unknown references blank. Do not replace the project's required checks with a generic list copied from another team's workflow.
Open the complete example · Download the full HTML source
Compare two small release packets
This original fictional example has no real repository, build, test run, or published software. Its identifiers are teaching labels, not commit hashes or native build-system output.
Packet A: intended version 1.2.0; artifact label build-A; verification record TEST01 identifies build-A; release-note version 1.2.0. Actual source revision and publication record are not supplied.
Packet B: the same intended version and release-note version, but the artifact label is build-B. TEST01 still identifies build-A. That record cannot establish verification of build-B.
The example's local comparison reports whether the artifact label matches the supplied test-record label. For Packet A, they match. For Packet B, they differ. A match answers one identity question; it does not certify release readiness. Neither packet establishes the missing source revision, required test coverage, release authority, or actual publication.
Make each check point to the same candidate
Ask which exact source produced the candidate, which artifact was inspected, and which artifact the test result identifies. Use the project's actual immutable references or checksums where required; a handwritten version label alone may not distinguish two different artifacts.
An identity comparison can be as small as this supplied-record check:
const packet = {
artifact: 'build-B',
testRecord: 'TEST01',
testedArtifact: 'build-A'
};
console.log({
record: packet.testRecord,
sameArtifact: packet.artifact === packet.testedArtifact
});
For these literal inputs, sameArtifact is false. This code does not run tests, authenticate a test report, or inspect a binary. It compares the supplied labels. The worked HTML lets you switch between the two packets and inspect the records alongside the result.
Separate a release draft from publication
GitHub's release-management documentation distinguishes choosing a tag, selecting a target when creating a tag, attaching assets, and saving a draft or publishing. Follow the actual repository workflow and permissions; the HTML example performs none of those operations.
Keep release preparation and publication as separate checklist fields. After an authorized publication, retain its actual reference and check the artifact exposed through that route. A prepared release-note page or a local label comparison is not a deployment, installation, or observation of users receiving the change.
Copy a candidate-bound checklist request
Create a complete HTML software-release review packet.
Project procedure and required checks: [PASTE]
Intended version/tag and exact source revision: [SUPPLY]
Actual artifact reference and verification records tied to it: [PASTE]
Confirmed changes, compatibility notes and required release owner: [PASTE]
Actual publication route/record, if publication occurred: [SUPPLY]
Connect each check to the same candidate and evidence reference.
Flag different or missing identities without inventing a test result.
Separate a matched label from test coverage, approval and publication.
Include a blank reusable record. No fake hashes, builds, test reports,
deployment, uploads or automatic approval. Label invented examples.
Any local comparison must describe exactly what it compares.
Return full self-contained HTML and unresolved candidate questions.
The release-notes template explains the changes users need to act on. Keep that communication aligned with the actual candidate checked here. Resolve an artifact mismatch in the maintained build and test records before advancing the real release procedure.