Disclosure: This draft was generated with AI and checked against the cited primary sources, with a separate AI editorial review. It was prepared for the FrameSprite team, which has a commercial interest in FrameSprite. Proposed examples are not executed tests unless explicitly identified as recorded fixture results.
Record the resolved commit identifier with an art release tag. A tag is a convenient name, but a name alone is not a durable identity guarantee. If someone moves that name, recipients can build different sprite packages while both believe they used the same release.
Key Takeaways
- Store the tag name and resolved object identity together.
- Publish a new revision when accepted delivery files change.
- Distinguish signing, access control, and immutability.
A release label is not the texture itself
The Git tag manual distinguishes tag forms and documents replacing existing tags. A signed tag can help validate the signed object, but signing does not mean that every hosting platform will prevent future movement of a similarly named reference.
Treat characters-v1 as a human label and the resolved commit as the source revision. Keep the exported package's identity separate because build tools, export settings, or dependencies can change the package even when source art looks the same.
This distinction matters when a contractor, build server, and programmer download at different times. A conversation saying “use v1” gives them no way to resolve a disagreement about which pixels were approved.
Publish a revision record
For each delivery, record the release label, source commit, export tool version, export command or preset, package filename, and verification method. Include any external inputs needed to reproduce the output. Do not put credentials or private source references into a public record.
Compare the intended source and delivery changes using the Git diff documentation. An unchanged atlas path does not mean the atlas is unchanged. Review texture bytes and decoded pixels according to the question being asked.
When approved art changes, prefer a new release identifier with a short explanation. Keep the earlier delivery available according to the project's retention policy. This lets a recipient reproduce an old build without interpreting a mutable “latest” link.
Example: the corrected walk cycle
A team releases ranger-art-1.0 with a walk cycle. Later, an artist replaces a foot pose and moves the tag to the new commit. A programmer who already fetched the original and a CI runner fetching today can now disagree about the same tag.
A clearer handover is ranger-art-1.0.1, linked to its own source commit and package. State that the right-foot contact pose changed, list affected actions, and identify whether the original release is still suitable for existing scenes. Do not silently replace a delivery used by a released game.
Verify at the recipient boundary
Test a new checkout or download using the recorded revision. Verify its package contents and review the relevant sequence. If a merge introduced changes after tagging, the tag must identify the revision intended for delivery, not just a nearby artist commit. The merge documentation describes that history operation; visual approval still belongs to the delivered content.
Accept the release when a recipient can identify both the approved source revision and the exact package. If the hosting service supports immutable releases, verify its settings separately. This guide proposes a traceability procedure and does not report a tested release pipeline or guarantee byte-for-byte reproducible builds.
Continue the workflow
Use the How do I prove a sprite manifest and texture belong to the same revision? for the neighboring problem. Keep the animation handoff checklist with the delivered package, and preserve its visual decisions in the game-art reference board.
Sources and editorial responsibility
Prepared by the FrameSprite Workflow Team. See the editorial method or contact the team with a reproducible correction. Sources checked 2026-10-20.
Top comments (0)