One link for every revision of a board
Why a board's link should outlive its revisions, and how BoardRepo keeps one address on the latest version while every older version stays numbered, linkable and downloadable.
Published · Updated
Hardware links go stale quickly. A shared-drive folder gets reorganised, a zip attached to an email is superseded by the next email, and a link to a file in a repository points at whatever that file became. The README, the issue tracker and the fab's order history end up pointing at three different revisions, or at nothing.
A board page on BoardRepo is built so that one address stays right.
The link follows the latest version
A board lives at one address, boardrepo.com/<owner>/<board>. That address opens the latest published version. Changed source can arrive through uploads, GitHub tracking, the KiCad plugin, or an approved personal assistant save. An unchanged tracked import or plugin push does not add a version. Use the current address for ongoing work, and a specific version link for a review or manufacturing decision.
Older versions keep their own links
Open Version history on the board to see every published version with its note. Opening an older one selects its number, such as v=3. The Share control still copies the latest-version link. To send revision 3, copy the complete Share link and append ?v=3 if it has no query, or &v=3 after its existing token query. Keep the access token intact; the address bar of an opened restricted board can omit it. That version link still selects revision 3 after revision 4 exists. Each version keeps its retained source files and successfully processed views. Check the upload review for excluded files. The sharing guide explains the recipient's browser, download and plugin access.
Tracking a GitHub repository
If the design already lives on GitHub, import the repository instead of uploading zips. With the BoardRepo GitHub App installed and Keep up to date selected, default-branch changes can produce new source versions. This tracks GitHub into BoardRepo; an assistant save or KiCad Push does not automatically commit back to GitHub.
A shared team history
An organization owns its boards and saved versions. Members work within the viewing and publishing access assigned to them, and the history stays with the organization when someone leaves. Use the web workspace or KiCad plugin to save shared work with publishing access. A connected assistant can inspect separately approved team context; organization saving through MCP is planned. Share a board privately explains board grants and access links.
What belongs in a version
A version is only useful if it opens. Upload the whole project folder: the schematic and layout, the libraries they reference, the 3D models, and the fabrication outputs you actually ordered. Add a short note saying what changed and why. Version control for PCB designs covers the routine in more detail, and version control for KiCad projects covers what to commit if the board is also in git.
Going back
Restoring an older version as the latest is one action in Version history. It creates a new version rather than rewriting the old ones, so the board's address moves back to that revision and the history still shows what happened. Two published versions with compatible, available comparison data can be compared on the board. Restoring on BoardRepo does not change local KiCad files: download the intended version, or Pull when it is the current remote version offered by the plugin.
More in News.