It is actually very simple from OCF point of view: What OCF can certify must be in a spec: e.g. having a (spec) version. Even the data models.. When the data model is not yet released in a spec, it can’t be certified as being part of an OCF device.
Kind Regards, Wouter From: iotivity-dev@lists.iotivity.org <iotivity-dev@lists.iotivity.org> On Behalf Of Clarke Stevens Sent: Monday, July 30, 2018 5:42 AM To: Nathan Heldt-Sheller <nathan.heldt-shel...@intel.com> Cc: Gregg Reynolds <d...@mobileink.com>; iotivity-dev <iotivity-dev@lists.iotivity.org>; Mark Trayer <m.tra...@samsung.com> Subject: Re: [dev] IoTivity 2.0.0 release status update That is correct. We always tag a release of the data models with the release of the specification. While it’s true that the specification doesn’t affect the data models (or vice-versa) directly. There are things like features of the specifications and data models both tied to the release of support for healthcare. Maybe we don’t really need to tie them together, but it seems to be useful. Thanks, -Clarke On Jul 29, 2018, at 6:13 PM, Nathan Heldt-Sheller <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Mark can correct me if I’m wrong about this being true going forward, but up to now at least, I believe we’ve bound a snapshot/tag of the data models to the Specification release. They can continue to evolve between releases, but there’s a fixed version of them that’s bound to the version of the Specification against which a Device is certified to conform. Thanks, Nathan From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Sunday, July 29, 2018 3:01 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> Cc: iotivity-dev <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: Re: [dev] IoTivity 2.0.0 release status update On Sun, Jul 29, 2018, 4:06 PM Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Hi Gregg, I understand your points… for what it’s worth we’re aligning with the major.minor rev, and using the next point for bug fixes against a given Specification. So 2.0.x will implement 2.0, 2.1.x will implement 2.1, etc. There is also version info in the code, but we were creating a lot of confusion on the very simple question of “which code version should I grab to go along with verison x.x of the Specification?” Houston, we have a problem. Totally understand what you're saying. Buleeeve me I've thought about it. Today it dawned on me: there's a very big difference between a protocol and a data model. OCF conflates them. Consider: OCF could radically change the data model with no effect on the protocol. Or vice versa. Then what does conformance mean? Thanks, Nathan From: Gregg Reynolds [mailto:d...@mobileink.com<mailto:d...@mobileink.com>] Sent: Saturday, July 28, 2018 1:30 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> Cc: iotivity-dev <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: Re: [dev] IoTivity 2.0.0 release status update On Fri, Jul 27, 2018, 1:42 AM Nathan Heldt-Sheller <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Thanks Gregg, I tried to capture it in earlier notes to the list regarding tagging, but we (OSWG, at a weekly CC) decided to change 1.4 -> 2.0, in order to make it easier to determine which version of IoTivity implements which Specification set. I understand the motivation but respectfully it seems like bad idea to try to establish a semantic relationship between labels marking what implements and what is implemented. It's easy to see how this can and probably will go off the rails. (Bug fixes for both, enhancements for the code, etc.) The way to indicate what protocol version is supported by code is to stick some info in the code that says so. The version of the code text is a completely separate issue, and also completely separate from spec. (Does Iotivity 2.1.x support OCF 2.1 or just 2.0?) IoTivity is indeed not the only implementation (actually pair; IoTivity and IoTivity Lite are completely separate stacks). But IoTivity is currently the “feasibility proof point” for OCF Specifications so OCF Specifications must be accompanied by a corresponding IoTivity release implementing all mandatory functionality. So while separate they are definitely co-dependent ;) I’ll try to make this clear in the release notes, too. Thanks, Nathan From: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> [mailto:iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>] On Behalf Of Gregg Reynolds Sent: Thursday, July 26, 2018 3:41 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> Cc: iotivity-dev <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: Re: [dev] IoTivity 2.0.0 release status update On Thu, Jul 26, 2018, 5:34 PM Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Hi Gregg, Yes the release notes will be posted to the Wiki along with the release of 2.0.0 (and a link in the announcement email). These notes will include known issues (any significant Jira tickets that are not yet resolved) as well as a complete list of patches applied since 1.3.1. I also plan to get a “new for 2.0” feature summary from OCF and repeat it with the release notes. Well, I'm still a little confused about OCF 2.0 v. Iotivity whatever. There was talk about iotivity 1.4. what happened to that? Fwiw I think it useful to make a clean distinction between spec and implemetation. Iotivity is not the only possible implemetation of OCF. If there is other information you think would be nice to have, let me know. Thanks, Nathan From: Gregg Reynolds [mailto:d...@mobileink.com<mailto:d...@mobileink.com>] Sent: Thursday, July 26, 2018 3:11 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> Cc: iotivity-dev <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: Re: [dev] IoTivity 2.0.0 release status update On Thu, Jul 26, 2018, 10:27 AM Nathan Heldt-Sheller <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>> wrote: Hello Devs, an update on 2.0.0 release status: Unfortunately, there are still 3 or 4 Cert-blocking issues with IoTivity 2.0.0-RC1: https://jira.iotivity.org/issues/?jql=project%20%3D%20IOT%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Assigned)%20AND%20fixVersion%20%3D%20%22IoTivity%20Bangkok%22%20AND%20priority%20%3D%20P1%20ORDER%20BY%20updated%20DESC Worth noting is that these are not regressions over previous releases. These are issues that existed in 1.3.1, etc., but were not caught because the tests that are failing were not yet added to CTT during 1.3.1 testing. Because of this (the fact that previous releases have these same issues), we may decide to release 2.0.0 with these issues unresolved if we can’t get them closed very soon. The current 2.0.0-RC1 is still a big improvement over 1.3.1 and we’d like to make it available right away. Sounds good. Do you have a complete list of changes? Thanks, that would be great! However if we can get fixes for these done (and it appears a few may be fixed very soon) then we will go ahead and make a 2.0.0-RC2 tag to capture those fixes, and re-start QA for the final 2.0.0 release. Thanks, Nathan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9825): https://lists.iotivity.org/g/iotivity-dev/message/9825 Mute This Topic: https://lists.iotivity.org/mt/23823285/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
