There are times in life when a surprise is a good thing. Like when you get a box of chocolates. We all remember the line from the movie Forrest Gump, “Life is like a box of chocolates, you never know what you’re gonna get.” When you install a new version of software however, surprises aren’t as enjoyable. With a new software release, customers need to be able to assess the effort and impact the new release will have on their current systems and procedures. Then they can evaluate whether the new features and functionality will be worth the effort to deploy the new software release. One way software companies can help communicate the impact a new software release may have on customers is by using a clearly defined release versioning procedure.
Change is good and software products that grow and mature over time, adding new features and eliminating unwanted behaviors, can remain healthy and viable over a long period of time. However, consistency and predictability are also important characteristics of good software products. So how do software companies balance these two seemingly competitive objectives?

Many software companies can do this is through the way they use software versioning. It is common for software companies to use a major.minor.patch.build software versioning scheme, for example iTunes 12.3.1. This type of software versioning allows the software company to communicate the scale and impact of the changes in the release to their customers. A change in the “major” release number indicates to customers that there are some significant changes in this release that may impact the way it interacts with the product. The customer will likely need to make code changes or procedural changes when upgrading to such a release. A change to the “minor” release number denotes that there are multiple changes in the release, but customers should see only minor, or possibly no changes, in the way they use the product. A minor release may include some small new features that could potentially require code changes if the customers wants/needs those new features. A “patch” release is generally used to address a specific issue and should not change the customer experience with the software. The build number is most often provided to help the software company when researching a question or customer reported defect.
Software versioning provides a way to set expectations with the customer about what is in the release and how it might affect the way they use the product. It can help take the surprise out of the process of installing a new software release. Life may be “like a box of chocolates,” but software releases shouldn’t be.♦
If you would like to learn more about the semiconductor industry, software best practices, and other topics related to new technologies, please subscribe to our email updates using the form in the upper right corner of this page.





Last fall I was invited to attend the 30th Anniversary Celebration for Rorze Corporation and their partner company ADTEC Plasma Technology. The event took place at the Fukuyama New Castle Hotel in Fukuyama, Japan on December 14, 2015. As you may know, Rorze is an official distributor of Cimetrix products in Japan so we have a long-standing relationship including Rorze handling Cimetrix products as well as being an investor in Cimetrix Incorporated itself.
For a small company like Cimetrix, we can be proud of these accomplishments. We are very thankful to have had 




However, before diving into a detailed design process for an EDA factory system, you must decide what overall system architecture will govern that design. A number of factors go into this decision, including 1) the functional requirements that distinguish EDA-based data collection from other more traditional approaches, 2) technology constraints of the existing factory systems, 3) budget limitations, 4) schedule requirements, and especially 5) the non-functional requirements (scalability, performance, reliability, ease-of-use, etc.) that often make the difference between success and failure of a given system.
Moreover, when communicating these requirements to the OEM community, it is useful to explain what strategic manufacturing objectives are being addressed and what the information will be used for; this context helps the suppliers understand why the specs may include a high level of detailed information, and can shift a potentially adversarial negotiation process more towards a teaming relationship based on shared objectives.






