+1 Vladimir, Igor, Pavel Tupitsyn, what do you think?
-- Denis On Fri, May 25, 2018 at 11:26 AM, Pavel Petroshenko <pa...@petroshenko.com> wrote: > Hi Dmitriy, > > Agree, your proposal makes a lot of sense. > > p. > > On Fri, May 25, 2018 at 11:04 AM, Dmitriy Setrakyan <dsetrak...@apache.org > > > wrote: > > > I generally think that as a community we need to start taking an approach > > of separate thin client releases. This goes for Java, .NET, JDBC, ODBC, > > Node.JS, etc... > > > > We can still host them in the same Ignite repo, but they should be a > > separate download. Of course, they should be included in the overall > Ignite > > distribution as well. > > > > Node.JS client could be the first one to take this approach. We can then > > migrate others as well. > > > > Denis, Pavel, what do you think? > > > > D. > > > > On Thu, May 24, 2018 at 2:11 PM, Pavel Petroshenko < > pa...@petroshenko.com> > > wrote: > > > > > As Denis said, there is no need to download the entire Ignite repo to > > > install the client. Once published the client is going to be installed > by > > > users with a command: > > > > > > npm install -g apache-ignite-client > > > > > > The sources are going to be distributed as a part of the ignite > > repository, > > > yes. But in general, release and installation process for the client > and > > > the Ignite technically are completely independent. > > > > > > And moreover: if there is a bug, especially critical, found in the > client > > > we shouldn't wait for the next Ignite to be released to get it fixed. > We > > > should be flexible enough to push the fixes and release the clients' > > > updates independently at any point in time. > > > > > > Having an independent release/versioning scheme would allow the clients > > to > > > get bug-fixes (minor version update) or nonbreaking feature-adds or > > > improvements (medium version update) between major Ignite releases > > > (potentially breaking changes and thus - the major version update). But > > the > > > client and the Ignite versions mapping might be tricky and should be > > > clearly documented. > > > > > > So there are pros and cons. > > > > > > But I believe the release policy should be consistent across all the > Thin > > > clients (I'm not talking about the "native" or Thick ones, which > heavily > > > depend on the Ignite internals and are a different story). > > > > > > p. > > > > > > > > > On Thu, May 24, 2018 at 1:44 PM, Denis Magda <dma...@apache.org> > wrote: > > > > > > > Once the client is built it will be uploaded to the npmjs repository, > > > > right? So, a JS developer can download the client from there without > > > > touching the whole Ignite binary release. > > > > > > > > However, those who download the whole Ignite binary distribution will > > > find > > > > node.js there (as well as .NET, C++, JDBC and ODBC). > > > > > > > > -- > > > > Denis > > > > > > > > On Thu, May 24, 2018 at 1:06 PM, Dmitriy Setrakyan < > > > dsetrak...@apache.org> > > > > wrote: > > > > > > > > > On Thu, May 24, 2018 at 12:36 PM, Pavel Petroshenko < > > > > pa...@petroshenko.com > > > > > > > > > > > wrote: > > > > > > > > > > > Fair enough. Consistency with the other clients is a good > argument. > > > > > > > > > > > > > > > > > Pavel, I would discuss it a bit more. Does it really make sense > for a > > > > > node.js user to download the whole Ignite distribution just to get > a > > > > > node.js client? > > > > > > > > > > > > > > >
