Version control for a technical file so nobody works from an old draft

Version control sounds formal, but for a folding stool file it can be simple: every version gets a number and a date, every change gets a log entry, and only one version is marked as current. Without those three habits, a team sharing drafts by email will soon have several versions in circulation, each claiming to be the file, and no one will know which hinge description, which drawing, or which risk entry is correct.

The current version should be easy to recognise. It should live in one shared place, carry a clear current label, and be the version that everyone is told to use. Drafts should live elsewhere, labelled as drafts, so a team member who finds a draft by accident does not mistake it for the current file.

A change log is the heart of version control. For each version, the log should state what changed, why it changed, who changed it, and when. For a stool, a log entry might say that the hinge description was updated after a hinge wore during repeated folding, that the change was approved by the workshop owner, and that the new description applies to stools from a certain production date onward.

Change logs also prevent silent overwriting. If a team member saves over the only copy, with no log and no previous version kept, the history of the hinge change is lost, and a future reader cannot tell why the hinge description changed or what it said before. Keeping previous versions, marked as superseded, preserves that history.

Illustration: a team shares 40 stool file drafts by email and imagines that 20 of them, in round illustration terms, are outdated versions still being used by someone on the team. Those figures, as presented in Version control for a technical file so nobody works from an old draft, are invented, not measured. They show why email sharing alone is not version control: email preserves every draft, with no indication of which one is current, and a team member who searches an inbox will often find an old draft first.

The remedy is a single shared location for the current version, with email used only to announce a new version, not to distribute it. An announcement should point to the shared location and state the new version number, so recipients do not need to guess which attachment is current.

One person should own version control, even in a small team. That owner numbers versions, updates the log, marks the current version, and archives old versions. Without an owner, version control becomes everyone's job, which in practice means no one's job, and versions multiply unchecked.

• Number and date every version, and mark one version as current.
• Log every change with what, why, who, and when.
• Keep previous versions archived and marked as superseded.
• Use one shared location for the current version, with email only for announcements.

Version control often fails through small habits. A team member who saves a quick edit as final version, without numbering it, creates a competing current version. A team member who edits a printed copy and never updates the digital file creates a paper version that diverges from the digital one. Both habits seem minor, but they undermine the whole system.

Another failure is to version only the main document, while leaving drawings, specifications, and test notes unversioned. A stool file is a set of documents, and if only one document is versioned, the set as a whole has no coherent version. Every document in the file should carry a version and date, or be linked to the file version that contains it.

Close by testing version control: ask a team member to find the current stool file, the current hinge description, and the log entry for the last hinge change, using only the shared location. If they can find all three quickly, version control works. If they cannot, the system needs simplifying, not more rules.

Review version control whenever the stool changes, the team changes, or a new tool is adopted. A system that worked for two people may need adjusting for five, and a system that worked on paper may need adjusting for digital files, but its core habits, numbering, logging, and a single current version, should remain.