On Wed, Jan 3, 2018 at 4:43 PM, Dave Thaler <dtha...@microsoft.com> wrote:

> Gregg wrote:
>
> We have branches for this kind of stuff. General rule: nothing goes into a
> release that is not production-quality and officially supported. Otherwise
> what is the point of having releases at all, instead of mere tags?
>
>
>
> [DT] The master vs. separate-branch discussion is certainly relevant here
> and worth having.   Historically, iotivity culture has been to throw in all
> kinds of extra features and APIs (e.g., cloud support).   If you’d like to
> argue that such features should not be in the master branch until they are
> production quality (including using only APIs that only meet the public API
> requirements), that’s a fine discussion for the list here, and not specific
> to APIs so wider than just what I as API maintainer would cover.
>
>
>
> More below…
>
>
>
> *From:* Nash, George [mailto:george.n...@intel.com]
> *Sent:* Wednesday, January 3, 2018 1:37 PM
> *To:* Gregg Reynolds <d...@mobileink.com>; Dave Thaler <
> dtha...@microsoft.com>
> *Cc:* iotivity-dev <iotivity-dev@lists.iotivity.org>
> *Subject:* RE: [dev] Proposed API guidelines
>
>
>
> > The whole concept of "experimental API" makes little sense to me.
> "Release with experimental (i.e. non-production) APIs" strikes me as an
> oxymoron.
>
>
>
> > We have branches for this kind of stuff. General rule: nothing goes into
> a release that is not production-quality and officially supported.
> Otherwise what is the point of having releases at all, instead of mere tags?
>
> > 1.3 Internal APIs
>
> The theory behind experimental API is not a hard to understand as you may
> think.  It is code that has been developed and is intended to be
> production-quality.  Maybe the branch did not attract much attention or
> could benefit from more eyes looking at the code. Till it is merge with
> master it will not get the attention of the community. It is a way to
> introduce code that is believed to be ready for release but due to
> circumstances the developers want to leave it open to API breaking changes
> if something is discovered that was missed. A way to think of it would be a
> public beta for the code in question.
>
>
>
> Some OSS projects have separate STABLE vs BETA releases for this
> distinction.   Using George’s definition above, all iotivity releases would
> be BETA releases and none are STABLE releases.
>

Wait, so the recent 1.3.1 release is not STABLE?

I think we're kinda splitting hairs about the meaning of "release". To me,
a release is stable, contains no "experimental" code, etc. Usable for
production. A release will never change. Moreover, *published as such* -
not just another tag.

Experimental - which I take to mean no more than "under development" -
should never be "released". A release is fixed and stable; an
experimental/dev branch is by definition unstable- you should always pull
the latest version if you want to work with it, and it may or may not work.
If it does not, wait a while and pull again to get the latest fixes.


>    Splitting APIs into public vs experimental means the same release can
> have both STABLE and BETA APIs in the same release, to distinguish them.
>

"BETA release"?


>   That helps with that issue, but does not help with the issue of
> underlying features that might be BETA quality features that might affect
> STABLE features.
>

I don't see what the issue is. If you have some code on a feature branch
that might affect main, so what? Work it out, once it is stable you can
merge it to main and issue a new release with the new feature. What am I
missing here?  If you're worried about getting people to look at it,
publish as BETA (which is not a "release" as I understand it).

 -g
_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

Reply via email to