Just a humble opinion in here.. I've already said in another thread that
IoTivity release cycle is very weird.
>From my point of view 1.3 should't have any breaking changes, but it starts
with secured=1, different payload format and lots of new features.. This
release should be tagged 2.0 (What happened to 2.0 btw?)
That said, perhaps this project could adopt some conventions like MongoDB
or NodeJS has.. On MongoDB 3.x odd releases are developer preview and even
are production ready. On NodeJS odd releases are "current" and even are LTS.
In both cases developers are aware of what kind of support and stability is
expected in a given release.
regards,
On Tue, May 23, 2017 at 11:08 AM, Mats Wichmann <mats at wichmann.us> wrote:
> On 05/23/2017 03:11 AM, ??? (Uze Choi) wrote:
> > Hi Omar/Nathan
> >
> >
> >
> > Let?s these requirements for release kept from the next release.
> >
> > To cut the feature earlier, CTT also should align together, but
> practically this is not easy work.
> >
> > Anyway I felt that IoTivity and OCF need more communication and
> coordination.
> >
> >
> >
> > Practically September timeline is what we can think about for final CTT.
> (I expect one or two months delay)
> > mbedtls version will be updated by consequence patch just after release
> which might not change any API change.
> >
> > interopable issue is from the spec view, I think.
> >
> >
> >
> > To avoid people get confused, Let me post the release context with
> non-certifiable wording.
> >
> > Any suggestion will be welcomed except giving up this release.
>
> I'm not going to offer up an opinion for solving the present dilemma,
> but I do want to assure everyone that there is nothing new here: every
> large open source project has gone through some form of this discussion.
> There is a good reason why many mature projects have chosen to go to
> time-boxed releases rather than feature-boxed releases - the now
> familiar "we will release every six months" model. It is very hard to
> coordinate all the development in a volunteer project with worldwide
> distribution of developers, and having a predictable release schedule
> serves as such a coordination point for developers as well as for
> consumers of the project ("it helps", not "it magically solves
> everything"). Note that while most of the developers on IoTivity are
> corporate-sponsored, a very useful definition is: if the release manager
> does not have control over who works on what, it should be
> classified as a volunteer project. I could go on about this, but there
> is plenty of more reasoned argument out on the internet (Martin
> Michlmayer and others have done some fairly formal research on the topics).
>
> It is important to note, however that committing to time-based releases
> means several preconditions have to be met, one of which is: "the
> release rationale must not be driven by specific functionality". Similar
> to what Omar noted, this iotivity release seems to want to (a) attempt
> to implement a particular version of the OCF specifications and (b) have
> a quality metric that the codebase, if suitably configured into a
> "device" of the kind described by OCF specifications, can pass the
> certification tests (CTT) for that version of the OCF specification.
> That would make this a feature-boxed release.
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
--
*Thiago Guedes Cunha de Moura*
Graduando em Ci?ncia da Computa??o
Instituto de Ci?ncias Exatas e Biol?gicas - Universidade Federal de Ouro
Preto
cel.: (31)99484-9864
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170523/cb09af79/attachment.html>
