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> 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 > <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 > > <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 (#9824): https://lists.iotivity.org/g/iotivity-dev/message/9824 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] -=-=-=-=-=-=-=-=-=-=-=-
