Most problems in open hardware releases aren't design problems. The circuit works; the repository just doesn't let anyone else reproduce it. These are the checks we'd run before every tagged release. They take about an hour, and they catch the mistakes that otherwise arrive as confused emails months later.
Clone it fresh
Clone the repository into an empty folder on a different computer, or at least a different user account, and open the project from there. This one step finds most of the trouble: footprints that live only in your personal library, 3D models referenced by an absolute path on your laptop, fonts the silkscreen needs, scripts that assume your folder names.
If anything is missing, add it to the repository and repeat until the project opens cleanly.
Regenerate, then compare
Regenerate every production file from the sources: Gerbers, drill files, pick-and-place, BOM export, PDF schematic. Then compare them with the files you're about to tag. If they differ, someone edited a generated file by hand or forgot to regenerate after a change. Either way, the release would ship files that don't match the design.
A short script that regenerates outputs and fails when they differ is worth writing once you've done this manually a few times. Several EDA tools have command-line interfaces that make it practical.
Read the BOM as a buyer
Open the BOM and pretend you're ordering parts for five boards. Every line needs a manufacturer part number and a footprint that matches the layout. Look up the parts most likely to cause pain, the ones with long lead times or a single source, and add alternates. Check that "do not populate" parts are marked clearly so nobody orders them.
Put the revision on the board
The board should carry its revision in copper or silkscreen, and the same string should appear in the release tag, the changelog and the BOM file name. When someone sends a photo of a failing unit, the revision on the board tells you which files they have. Adding a source location, the URL of the repository, on the silkscreen helps too, and some licenses such as CERN-OHL v2 recommend it.
Check the licenses
Make sure every folder is covered: design files, documentation and firmware often carry different licenses. The README should say which applies where. Source files can carry an SPDX line, for example SPDX-License-Identifier: CERN-OHL-S-2.0. If you haven't picked yet, our license chooser takes about a minute.
Write the changelog for people with the old board
A changelog entry that says "fixes" helps nobody. Say what changed, why, and whether it matters to someone with the previous revision: "R12 changed from 10k to 4.7k to fix USB enumeration on some hosts; earlier boards can be reworked." That one sentence can save a user a week.
Then tag
Tag the release, attach the production files as a ZIP so people can order boards without installing anything, and keep the old releases where they are. Our longer guide to publishing an open hardware project covers the repository layout and documentation in more detail.