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