Version Controlled Library
We at Nine Dot Connects are often asked our opinion and recommendation about various library methodologies. One of the most commonly asked questions is if one should pursue a version-controlled library.
We believe version control in a library system is unnecessary. We see a need for such libraries when it is being mandated upon the company by an end customer or by an industry standard. Even the medical electronics industry, heavily scrutinized by the FDA, does not require version control libraries; they demand that the project is tightly controlled. Any subsequent changes to the project require review and, very likely, new clinical trials.
This is NOT to say that library files should not be kept in a document version control system for safekeeping. However, we question the need for version control at the component level.
Here are some points to consider:
- Version control will not streamline the library creation process. In fact, it only adds another task to the effort. The process to build a component remains the same, with or without the version control system.
- If the issue determines component status (prototype, production, sunset, obsolescence, etc.), this is a life cycle management issue. This is the direct result of having separate databases for engineers/designers, purchasers, and document control. This configuration's basic dysfunctionality is communication lags between databases, which can be measured in weeks and months. The optimal solution is to have one database handling all 3 needs. Version control does not help life cycle management.
- Components don't change once they mature. Granted, if there is something incorrect with the component, it will be changed; however, once a component is in the library and has been used successfully, it will not change over time. If any, the modifications are all made during the project, and those modifications are only going to improve the component. What about a component being developed by one designer and is found by another designer for another design? Again, this is a life cycle management issue. Version control will not alleviate this problem.
- If the component's manufacturer will make a physical change to the component, it is very likely they will change the component number. Besides, if one changes a component's footprint for the better (i.e., improves the thermal pad configuration, etc.), is that really an issue for the prior design or new designs? In most cases, the answer is 'Not for the prior design.' Even a change to a prior design generally does not entail a review of the existing footprints.
In summary, version control will not remedy a streamlined way of managing components flowing from the designers into a central library. This is what we at Nine Dot Connects call a 'point of entry' issue. All too often, components start incomplete, have missing or incorrect information, or are not formatted in an optimal way to maintain the company's overall look and feel of the library. The longer this component progresses through the project with errors or omissions, the harder it is to correct it throughout the entire project (or projects).
If you differ in opinion or have successfully implemented a version control database, please contact us. We would like to know the hows and whys.