Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <91F80F95-042B-49C5-AA1E-7A0E7D0DC374@apache.org>
References: <CAGt6o8nO6o8S1G3Qmc=Y_FALyKX_Dt2kY7y8wkMyEHX+acmwFg@mail.gmail.com>
 <CA+0=VoWgr=Bs_aUQAf6p3xDqW2LeADS60s-jrriE2zXt9TNvMw@mail.gmail.com> <91F80F95-042B-49C5-AA1E-7A0E7D0DC374@apache.org>
From: =?UTF-8?B?0J3QuNC60L7Qu9Cw0Lkg0JjQttC40LrQvtCy?= <nizhikov.dev@gmail.com>
Date: Fri, 15 Sep 2017 10:58:11 +0300
Message-ID: <CAG7t87_RXivNxhzLACRreAMwFz3vJKqZiRSCZa40A1VY4PkzCw@mail.gmail.com>
Subject: Re: Experimental features - thin client protocol as a first candidate
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="001a114108401fef29055935c132"
archived-at: Fri, 15 Sep 2017 07:58:19 -0000

--001a114108401fef29055935c132
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

I think it is a very useful concept to have.
Other Apache projects have this conception too.
As an example I can provide spark special annotation for a public API [1]

InterfaceStability {
   Unstable, Evolving, Stable
}

[1]
https://github.com/apache/spark/blob/master/common/tags/src/main/java/org/a=
pache/spark/annotation/InterfaceStability.java


2017-09-13 22:35 GMT+03:00 Denis Magda <dmagda@apache.org>:

> In first version the protocol version can be =E2=80=9C0.1=E2=80=9D, 0.2=
=E2=80=9D, etc. Once we are
> sure the protocol is mature enough it can be stamped with version 1.0.
>
> The point is that the versions like 0.x imply that the protocol is not
> 100% final which is pretty similar but not that loud as the experimental
> label.
>
> =E2=80=94
> Denis
>
> > On Sep 13, 2017, at 12:12 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
> >
> > Vladimir,
> >
> > As far as the client, I don't think we need to call it experimental. An
> > "experimental" feature sounds like it might explode if you come close :=
)
> >
> > How about we have client protocol versions instead? Then each Ignite
> > release can announce which protocol versions it is compatible with.
> >
> > D.
> >
> > On Wed, Sep 13, 2017 at 5:21 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> >> Igniters,
> >>
> >> I would propose to add a concept of "experimental feature". Quite ofte=
n
> we
> >> face a situation when newly created feature has not-so-good API, or
> tested
> >> insufficiently, etc.. Many vendors employ a concept of so-called
> >> "experimental" features to mitigate the risks. Examples I am aware of:
> >> Hadoop, Kotlin.
> >>
> >> When feature is marked as experimental, there is no guarantees for API
> and
> >> binary compatibility, neither it implies that the feature is bug-free.
> On
> >> the other hand, users might start using the feature right away and
> provide
> >> valuable feedback.
> >>
> >> Let's add such concept to our product, and it would make it much bette=
r!
> >>
> >> First candidate for this marker is our newly developed thin client. We
> put
> >> a lot efforts to make it extensible in future, but I doubt it is
> possible
> >> to take in count everything at once. Instead, I would rather release i=
t
> as
> >> "experimantel" in the scope of 2.3, and then finalize it as a part of
> 2.4
> >> based on user's feedback.
> >>
> >> What do you think?
> >>
> >> Vladimir.
> >>
>
>


--=20
Nikolay Izhikov
NIzhikov.dev@gmail.com

--001a114108401fef29055935c132--