I am much more concerned about the two concerns that Nathan raises as well as their side effects. And, on the other hand, I see very little benefit to releasing 1.3.
In my opinion for the release to be useful to anyone it needs to meet at least three requirements: 1. Meet basic certification for its feature set 2. Be interopable with previous releases 3. Be free of major security and quality issues Without the above three requirements I am not sure the release would be of use to anyone. Anyone doing interim work which didn?t have the above requirements could just take a snap of the 1.3-rel branch (or even master) and use that for their prototype or other work. They wouldn?t really need it to be labeled 1.3 as such. However, declaring a 1.3 release at this point would have negative consequences. For one, it would be a dead-on-arrival release, where even the features it is supposed to have wouldn?t really work properly. Companies trying to evaluate or use any of the new features can start building on incorrect foundation, and if/when such feature is fixed it may not work for them. For those companies or individuals evaluating IoTivity or OCF might conclude that the ecosystem is of low quality and not meant to interop with even previous releases and therefore untenable for their products. This would also undercut the goal of getting more contributors to the project. I do hear Uze?s concerns that by having the 1.3 release go past its scheduled release some of the resources that were originally meant to work may need to peel off to do other projects. However, declaring 1.3 done when it really isn?t, is not going to fix that problem. The release will still need to pass CTT and get its quality up, and declaring 1.3 done will, in my opinion, discourage others from joining the effort. Also it will create future headaches where it?ll set the precedent of having dead-on-arrival releases. Companies wanting to use IoTivity will need to figure out which releases are real and which ones are just half-baked. Figuring out which release will work with which other releases and to what degree will be a very difficult question to answer and would be a big headache for the ecosystem. In hindsight, I think it would have been better to cut some of the features earlier on. This would have made the CTT gap smaller, and would have prevented a bunch of the churn and bugs that came with introducing those features late. We do still have that lever to some degree though, where if some feature(s) proves to be too burdensome to pass we could disable it for the time being and move it to the next release. It will not solve the problem to the core, but might reduce the time and burden to some degree. Thanks, - Omar From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Heldt-Sheller, Nathan Sent: Monday, May 22, 2017 11:10 AM To: uzchoi at samsung.com; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Regarding IoTivity 1.3.0 release objective Hi Uze, Thanks for doing such as excellent job tracking all these issues and concerns and trying to hold to a successful schedule. In my opinion, as long as people are clear that 1.3.0 cannot be certified as either OIC 1.1 or as OCF 1.0 then it is okay to create the release, as a way to mark a relatively stable reference for OCF 1.0 feature preview, for purposes such as beginning vendor application integration etcetera. I do not object to creating a release, if it is useful for member companies? we want OCF to be adopted and be successful, after all! However I have two concerns: 1. This ?non-certifiable? 1.3.0 may be used as a basis for more than it is intended, and since it is not tested yet against complete 1.0 CTT, I am quite certain it contains issues and gaps with the Specifications and their required behavior, even if we haven?t identified them yet. Are we certain vendors will not ship OCF 1.3.0 based products and create interop issues in the field? 2. I also am concerned that with the Amsterdam schedule being so tight, we will skip ahead and start building Amsterdam on an incomplete foundation of 1.3.0, without first completing OCF 1.0 implementation (including all bug fixes and un-discovered feature gaps). That said I think if we commit to driving hard to close all remaining gaps and bugs with full OCF 1.0 CTT then I don?t see harm in releasing 1.3.0, again if it is useful to member companies to do so. But in my opinion, if we are not very disciplined, I think the above two concerns are likely to cause us trouble down the road. Sincerely, Nathan From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of ??? Sent: Monday, May 22, 2017 10:35 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] Regarding IoTivity 1.3.0 release objective Hi All, Today I heard that there are lots of concern for 1.3.0 release in a hurry. But I'd like to share some background for this. Originally IoTivity has a plan to sync up with spec and certifiction schedule. However, there OCF 1.0 spec has been delayed and eventually this caused the misalignment with CTT final and IoTivity 1.3.0 release.
