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. The only time we see a need for such libraries is when it is being mandated upon the company by an end customer or by an industry standard. Even in the medical electronics industry, heavily scrutinized by the FDA, does not require version control libraries; they simply 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 is determining 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. The basic dysfunctionality of this configuration 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’s not going to change over time. The modifications, if any, 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 manufacture of the component is going to 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 for 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, the use of version control will not remedy issues pertaining to 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 off 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 provide your input in the comment section. We would like to know the hows and whys.