Project Data and Versioning

Preserve both the source history and the exact files delivered. They answer different questions: how the design developed, and what a user actually received.

Source Files and Release Data

Keep the native FontLab project as the working record. VFC provides compact storage; VFJ provides structured JSON text for review and version control. Omitting optional session data can reduce unrelated source-control changes. An exported OpenType font is a product, not a complete source backup: target formats can omit guides, source references, tags, annotations, and other development data. Preserve and version the native source rather than reconstructing the project from exports; recall Understanding Font Formats, Saving and Closing Fonts, and The Export Process.

Archive every delivered release exactly as sent: font binaries, web packages, license text, read-me files, documentation, specimens, and any installers or keyboard material supplied with it.

Record filenames and formats, public version, build date, source revision, profile/tool versions, delivery channel, and the relevant recipient or release destination. Checksums help identify whether a later file is the same artifact.

Keep release archives unchanged and backed up separately from the active working folder, including an off-site copy. Retention should follow the project's support, contractual, and organizational needs. A later rebuild is not necessarily byte-identical to the file a customer uses, even when its visible design is similar.

Exact artifacts help reproduce support problems, assist deployment, compare regressions, and establish release provenance. Release dates and exact contents can also support records of origin, authorship, and licensing history. Preserve the accompanying license and documentation too; they are part of the delivery context.

Project Versioning

Working revisions and public font versions are separate. You may save many experiments before issuing one numbered release. Tie each release to its source snapshot and changelog, keeping the public version consistent with the head/name fields and release scheme from Completing Font Metadata.

For a manual history, keep dated milestone copies distinct from the live working file. A name such as Family_2026-10-06_before-kerning.vfj sorts naturally and states why the snapshot exists. Preserve a copy before broad outline conversion, master restructuring, or batch hinting.

Autosave, backups, and Undo are useful recovery aids, but they do not replace a documented project history. A mask can preserve a local drawing reference; it is not a backup of the font's naming, kerning, features, and export settings.

For text-based source control, review changes at the appropriate file scope and keep generated release artifacts separate from everyday experiments. External version control provides commits, branches, and release tags for those source files. Keep the working-history discipline independent of a particular editor integration.

Maintain a changelog describing user-visible changes and known limitations. Distinguish a beta build from a public release, and record whether metrics, encoding, layout behavior, or names changed. This helps a collaborator understand the practical effect of an update.

Project Data and Handoff

Keep supporting files with the source or in documented locations: feature includes, .enc, .nam, .cpg, uranges.dat, alias.dat, kerning phrases, reference artwork, scans, and the design brief. The customizable files and user-data hierarchy are taught in The User Data Folder and Customizable Data Files.

Record which custom data files are actually required. A collaborator should not have to guess that a recipe depends on your personal alias.dat or that a feature includes a file outside the project folder.

A useful handoff contains:

  • The versioned native source and required external data.
  • The intended export profiles and reproducible build notes.
  • The release archive and its source-revision mapping.
  • Current known issues, proof strings, and review status.
  • The meaning of project tags and color flags.

Use the Important Font Note as a short opening read-me, with glyph and element notes carrying local decisions. Keep sensitive recipient or account information in an appropriate project record rather than unnecessarily embedding it in a source font that will be widely shared.

Confirm the recipient can open the project and locate its dependencies before treating the handoff as complete. Preserve the authoritative source and identify which files are references, experiments, and deliverables.