In my opinion, if a certain feature is experimental, we should simply
mention it in the release notes and/or documentation. I would not create a
separate beta release just for a certain feature.

D.

On Tue, Mar 1, 2016 at 6:57 AM, Pavel Tupitsyn <ptupit...@gridgain.com>
wrote:

> Hi,
>
> I don't think that features like LINQ and ODBC need the same approach
> as IDEA EAP. IntelliJ has EAP because new features may have bugs
> or usability issues. With LINQ and ODBC our main concern are not bugs,
> but unsupported use cases that we did not think of. Known use cases
> are covered with tests.
>
> Beta releases may not get enough attention to gather feedback.
> I think we should release these features right away and gradually add
> support
> for missing use cases, if any emerge. We are not going to change API or
> break compatibility while adding these things in future.
>
> Furthermore, LINQ is only a usability feature. Users can always switch to
> raw SQL
> if something can't be expressed in LINQ.
>
> On Tue, Mar 1, 2016 at 10:44 AM, Vladimir Ozerov <voze...@gridgain.com>
> wrote:
>
> > Igniters,
> >
> > I want to circulate again an idea of "betas" for particular product
> > features.
> >
> > For now we have several pretty cool features which are to be released
> soon:
> > ODBC driver and LINQ in .NET. Features like this include potentially
> > infinite amount of use cases and of course we cannot test all of them. I
> > believe things like this should go through extended release cycle so that
> > we have time to get user's feedback before officially announcing them. It
> > could be betas, early previews, whatever.
> >
> > The main idea is that we have a time window to obtain a feedback and
> > stabilize the feature.
> >
> > This is a common practice for more or less big products. E.g. see
> Hazelcast
> > python client [1] and Intellij IDEA EAP 16 [2].
> >
> > Thoughts?
> >
> > [1] https://pypi.python.org/pypi/hazelcast-python-client
> > [2] https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP
> >
> > Vladimir.
> >
>

Reply via email to