After you pick: sharing, versions and review

Your editor designs the board. Knowing which version went to the fab, letting someone review it without installing CAD, and publishing it safely are separate jobs, and most editors leave them to you.

Last reviewed:

Three jobs your editor probably doesn't do

  • Version history. Every revision you ordered, what changed between them, and the sources for each.
  • Review. A teammate, a client or an assembler looking at the schematic, layout and BOM, ideally without installing your editor.
  • Sharing and publishing. Sending a board to one person, a team or the world, with the right access and the right files.

Altium Designer, Flux, EasyEDA Pro and Autodesk Fusion keep versions in their own cloud. KiCad, the top-ranked editor, keeps your files on your computer and leaves all three jobs to you. That's what this page is about.

Git or a purpose-built repository?

Git is free, everywhere and excellent for firmware. KiCad's files are plain text, so Git stores them happily and records every change. The trouble is what you see: a diff of a PCB file is a list of changed coordinates, not a picture of the board. Reviewers need extra tools such as KiBot (generates outputs in continuous integration) or Kiri (visual diffs of KiCad projects), and someone has to set them up and keep them running.

Purpose-built hardware repositories start from the board: upload a project and it opens as a schematic, PCB, 3D model and BOM in the browser, with saved versions you can compare visually. You give up some of Git's power (branching and merging, pull requests) for something a reviewer can use in a minute.

Many teams use both: Git for firmware and as the system of record, and a hardware repository so that people who don't live in Git can see and review the board.

The options, judged on the same criteria

These aren't PCB editors, so they aren't in the ranking. They're judged on the same criteria where those apply (cost and licensing, learning curve, file support, platform support and collaboration), with their limits stated the same way.

Git with GitHub or GitLab

Best for: Teams that already keep firmware in Git and want the board in the same repository.

Cost and licensing
Git is free and open source. Hosts have free tiers; check GitHub's or GitLab's pricing pages for limits.
Learning curve
Steep if you've never used Git, and its concepts (branches, merges, rebases) were designed for code.
File support
Stores anything. KiCad's plain-text files show line-by-line changes; binary formats are stored whole, and large files may need Git LFS.
What you can see
Text diffs. To see the board you add tools: KiBot generates fab outputs and documents in continuous integration, and Kiri shows visual diffs of KiCad projects.
Platform support
Everywhere.
Collaboration
Pull requests and code review, but reviewers read text changes to board files, not the board.

Limits

  • A line-level diff of a PCB file isn't readable as a board without extra tools.
  • Merging two people's edits to the same board file can corrupt it; treat board files as one editor at a time.
  • Someone has to set up and maintain the tooling.

Verdict: Right when the team already lives in Git; add a visual view for reviewers. git-scm.com

AllSpice

Best for: Larger hardware organisations that want Git-based revision control, review and automated release workflows.

Cost and licensing
Enterprise plans on managed cloud or self-hosted; pricing on request.
Learning curve
Built on Git concepts and set up with AllSpice's team.
File support
Check AllSpice's documentation for the EDA tools it supports.
What you can see
Version history with visual diffs between changes.
Platform support
Browser, managed cloud or self-hosted.
Collaboration
Design reviews with feedback on the source files, approvals, release automation and an AI design-review agent.

Limits

  • No public self-serve price: you book a demo to start.
  • Sized for organisations rather than individuals or hobbyists.

Verdict: Worth a look for enterprise teams with formal release processes. allspice.io

Your editor's own cloud

Best for: Teams whose members all use the same paid or cloud editor.

What's included
Altium 365 (with Altium Designer), Flux's shared projects, EasyEDA Pro's saved versions and branches, and Fusion's cloud projects all keep versions inside the tool.
Learning curve
Nothing new to learn if you already use the editor.
Collaboration
Varies: from saved versions (EasyEDA Pro) to comments, browser review and co-authoring (Altium 365, Flux).

Limits

  • Everyone who edits needs the same editor, and often a paid seat.
  • History stays in the vendor's service; check how you would export it if you leave.

Verdict: Convenient when the whole team is on one tool and plans to stay there. Altium 365

A version and review routine that works

  1. Keep each board's sources together in one project folder: schematic, PCB, project-specific libraries and the project file.
  2. Save a version at every milestone that matters: before review, after review, and the exact files you send to the fab. Give it a name you'll recognise in a year ("rev B, sent to fab").
  3. Share a browser link for review, so reviewers can look at the schematic, PCB, 3D view and BOM without installing anything.
  4. Agree who is editing. No tool on this page merges two people's simultaneous edits to the same board safely.
  5. When you order, keep the fab outputs with the version they came from, so a returned board can always be traced to its sources.

Publishing a board safely

Before you make a board public, work through this list.

  1. Choose a licence and include it. Hardware has its own licences, such as the CERN Open Hardware Licence (strongly reciprocal, weakly reciprocal and permissive variants). Without one, others can look but not legally build on your board.
  2. Strip what shouldn't be public. Check title blocks, text layers and BOM fields for customer names, internal part numbers, supplier account details and notes meant for the team.
  3. Check what's embedded. Recent KiCad releases can embed fonts, 3D models and datasheets in project files. Make sure you have the right to redistribute anything embedded, especially vendor 3D models.
  4. Publish outputs for each release. Alongside the sources, include the Gerber, drill, BOM and pick-and-place files you actually ordered, so people can build exactly that revision without opening CAD.
  5. Write a short README. What the board does, its revision, known issues, and how to order it. Most people decide whether to build a board from the README and a picture.
  6. Look at it the way visitors will. Open the public link in a private browser window and check that the schematic, PCB and 3D view render before you announce it.

Still choosing an editor? Start with the ranking or the picks by use case.