I fear this ship has long since sailed. We have integrated this repository within our codebase and we are now at a stage where we want to update from BSI_FLEX_335_v1.0 to BSI_Flex_335_v2.0_SAPIENT. I see this version is actually both V1.0 and V2.0 and I'm questioning the logic of this. I assume this decision was to make it easy for implementers of fusion nodes to support both versions at once. From an implementer of edge nodes perspective there is no advantage to having both versions and anincreased risk of mixing versions in error. I wonder if there is another mechanism that could be used by Fusion node implementers that would allow two versions to be used simultaneously whilst keeping the specific versions clean for Edge node implementers.
I am also now confused as to the meaning of FileOptions standard_version in proto_options.proto which I had assumed to refer to the bsi standard.
I fear this ship has long since sailed. We have integrated this repository within our codebase and we are now at a stage where we want to update from BSI_FLEX_335_v1.0 to BSI_Flex_335_v2.0_SAPIENT. I see this version is actually both V1.0 and V2.0 and I'm questioning the logic of this. I assume this decision was to make it easy for implementers of fusion nodes to support both versions at once. From an implementer of edge nodes perspective there is no advantage to having both versions and anincreased risk of mixing versions in error. I wonder if there is another mechanism that could be used by Fusion node implementers that would allow two versions to be used simultaneously whilst keeping the specific versions clean for Edge node implementers.
I am also now confused as to the meaning of
FileOptionsstandard_versioninproto_options.protowhich I had assumed to refer to the bsi standard.