Versioning of CAPE-OPEN
Malcolm WOODMAN, U.S. Environmental Protection Agency (represented by Bill BARRETT), Michael HALLORAN (Contractor to CO-LaN), Bryan Research & Engineering (represented by Michael HLAVINKA), Michel PONS (Contractor to CO-LaN / CTO)
- End-user of software implementing CAPE-OPEN
- Software vendor with existing implementations of CAPE-OPEN
- Software vendor wanting to implement CAPE-OPEN in its software for the first time or wanting to upgrade CAPE-OPEN interfaces
The definition of a strategy for versioning is necessary to cope with a number of situations (“use cases” of versioning) CO-LaN is facing now or soon:
- insert Flowsheet Monitoring as a new interface specification in the CAPE-OPEN standard,
- properly deprecate Thermo 1.0 as decided at the CAPE-OPEN 2017 Annual Meeting,
- modify ICapeUtilities::Edit in order to inform the caller that changes or no change have been made to the configuration.
- migrate to COBIA
Michel PONS reminds that the deprecation of version 0.9.3 of the CAPE-OPEN standard went through nicely, apparently because it was a self-contained version. The deprecation was applied by PME vendors who had implemented version 0.9.3. In the case of version 1.1 of the CAPE-OPEN standard, it contains also version 1.0 and makes it difficult to express the deprecation of Thermo 1.0. M. HALLORAN points out that since there is no common piece of software distributed by CO-LaN in between a PME and a PMC communicating over CAPE-OPEN, CO-LaN can’t force the deprecation: there is nothing in the way. M. HLAVINKA concurs that physically deprecating cannot be done. Deprecation should lead at most to a recommendation for a new implementation. He also proposes that a “deprecated’ watermark should be put on deprecated documents to make it more evident.
Introducing the Flowsheet Monitoring interface specification could be done in version 1.1 as long as version 1.1 of the CAPE-OPEN standard is itself versioned in how it is distributed. The third digit (now 0) could be used for that as long as it refers to a DLL type of file. M. HLAVINKA explains that the year (now: 18) and the day of the year (now: 267) are often used to make up the third digit (now: 18267). The end-user would be always presented version 1.1 but a developer would be able to build software against the latest version of 1.1 without preventing interoperability to work.
M. HALLORAN will investigate use of the 3rd digit in version number and how the CAPE-OPEN Type Library can be embedded in a DLL so that it is made clear to Windows installer which is the latest version of the same branch of CAPE-OPEN. He will also look into how using this 3rd digit addresses the four Use Cases considered.
Next conference call is scheduled for October 15, 2018.