A component marked out of date is not automatically wrong, and the newest library revision is not automatically approved for an existing product. Decide which revision the design should use by reviewing the actual differences and their consequences. Then preserve that choice in the release record.
Altium’s detailed item view documentation describes item revisions, lifecycle states, and comparison information. These features provide evidence for a revision decision; they do not replace the engineering assessment of whether a change belongs in a particular design.
Establish the current dependency
Record the component item and revision used by the placed instance. Identify its symbol, footprint, model, parameters, and relevant part choices. A familiar display name can remain unchanged while one of those dependencies changes.
Read the reason for the proposed update and inspect the available comparison. Distinguish a corrected pin mapping from a description cleanup, sourcing change, or mechanical-model adjustment. Their consequences differ, and a blanket “update all” operation hides those distinctions.
Map differences to design effects
| Changed content | Review consequence |
|---|---|
| Symbol or pin mapping | Connectivity and schematic interpretation |
| Footprint geometry | Placement, routing, soldering, and fabrication outputs |
| Parameters or part choices | BOM identity and purchasing instructions |
| Mechanical model | Clearance review and enclosure collaboration |
Check every placed use of the component in the project. A corrected library revision may affect several instances or variants differently. Keep the instance list available so that the review does not accidentally cover only the first occurrence. Note whether inherited model revisions are fixed or resolved through another library dependency, and include that relationship in the comparison.
Adopt or retain with a reason
- Compare the current and candidate revisions.
- Assess the change against this product’s requirements.
- Apply the update in a controlled design revision when appropriate.
- Review synchronization and regenerate affected outputs.
- Record the selected component revision and decision.
If a needed correction cannot be adopted immediately, record the remaining issue and its disposition. Merely pinning the older revision does not make a known defect acceptable. Conversely, retaining a qualified revision for an unchanged build can be reasonable when the newer revision addresses a different use.
Check that the release can be reconstructed with the selected dependencies. A link that always opens the latest library state is insufficient evidence of what was built. The goal is a reproducible design dependency and a documented reason for its revision, rather than a dashboard in which every component happens to display the newest status.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist