The GNOI version field in GNSI protos is not being kept in sync (version.proto=1.6.3, latest release tag=1.4.5) and is creating a circular dependency where GNOI depends on GNSI and GNSI depends on GNOI.
It isn't clear that this version field is adding value; it is rather difficult to access (for Go clients) and we haven't published any libraries to make this easier to grok. Since I suspect this is not currently used, I am opting to remove until we have some client libs and concrete users to access the field. If we are going to keep the version field, we should do it a bit differently (define the version in a new proto repo, import the same proto extension in all OC repos). It doesn't make sense to have the GNSI protos have a GNOI version number.
Additionally, update regenerate-files.sh so the executable bit isn't set on generated files.
The GNOI version field in GNSI protos is not being kept in sync (version.proto=1.6.3, latest release tag=1.4.5) and is creating a circular dependency where GNOI depends on GNSI and GNSI depends on GNOI.
It isn't clear that this version field is adding value; it is rather difficult to access (for Go clients) and we haven't published any libraries to make this easier to grok. Since I suspect this is not currently used, I am opting to remove until we have some client libs and concrete users to access the field. If we are going to keep the version field, we should do it a bit differently (define the version in a new proto repo, import the same proto extension in all OC repos). It doesn't make sense to have the GNSI protos have a GNOI version number.
Additionally, update regenerate-files.sh so the executable bit isn't set on generated files.