Re: [VOTE] Disconnect all non-C API's from mxnet versioning

-1 . for the reasons already mentioned, specially bad user experience. On Tue, Mar 13, 2018 at 3:20 PM, Nan Zhu wrote: > -1, I cannot think about a significant benefit comparing to the headache of > the user > > still take Spark as an example > > if PySpark is in a

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

-1, I cannot think about a significant benefit comparing to the headache of the user still take Spark as an example if PySpark is in a separated repo, say now it's 1.0, can you tell me whether this 1.0 support Arrow integration without going to their website and carefully check which version of

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

-1 Because of the customer pain-points mentioned by others. I think for good customer experience, all code in MXNet repository excluding submodules and 3rd party dependencies should map to the same version. Anirudh On Mon, Mar 12, 2018 at 4:17 PM, YiZhi Liu wrote: >

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

@YiZhi Well let's agree to disagree on this one I guess. There's some pretty strong -1s here, and this is clearly a code change so I think it's good that we had the vote and can move past the issue. I'm also not opposed to moving to 2.0. On Tue, Mar 13, 2018 at 12:17 AM, YiZhi Liu

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

Kellen, we are not talking about using wrong native package AFTER downloading the package. It's about deciding which version to use BEFORE downloading, and collecting information to debug. Copy-paste my previous words, " 1. It is harmful to user experience 1) Each time users want to use a

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

@Rahul + Roshani, I would hear what you're saying if the user had to worry about using the native package, but that worry is abstracted from them. The scala package has a dependency on the native library and includes the native lib inside the jar. The correct lib is then bound against at runtime.

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

-1 for the frontends having different versions than the backend. It not only creates confusion for new users, but also increases the work of developers who need to ensure compatibility. All this for a one-time change of namespace of a package? I think we should increase the major version number

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

-1 for different versioning. I feel its just added confusion for users. On Mon, Mar 12, 2018 at 2:35 PM, YiZhi Liu wrote: > Agree. > > And my reply to Marco's point, > > > Changing namespaces is one use-case, but there will be a lot more with > increasing activity - we

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

Agree. And my reply to Marco's point, > Changing namespaces is one use-case, but there will be a lot more with > increasing activity - we have to take the bigger picture in mind. And you mentioned the CPP package as an example. > During analysis, we figured that a re-engineering of that API

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

Please cast your vote only on the subject at hand. This is leading to confusion and unnecessary discussion/wasting time, you can start a new thread if you so like. I really would want to make progress on getting the Scala API to this release. On Mon, Mar 12, 2018 at 2:11 PM, Chris Olivier

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

Marco, you're mixing votes again. * This leaves us with three options: 1. Vote failed: No refactoring of user-facing APIs (including namespace changes) possible OR major version increase 2. Vote succeeded: Refactoring of user-facing APIs possible and only users of the changed APIs are

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

Regarding #4: Changing namespaces is one use-case, but there will be a lot more with increasing activity - we have to take the bigger picture in mind. I think it is safe to say that the other APIs have not been maintained as actively as our Python/Gluon API (which I would say could be versioned

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

STRONGLY -1 (binding) as I explained in another thread 'Publishing Scala Package/namespace change'. I think separating version is harmful. 1. It is harmful to user experience 1) Each time users want to use a specific feature, need to first check the mxnet core version, then check which

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

-1 for different versioning, it not only be maintenance nightmare but also more importantly confusing to users, On Mon, Mar 12, 2018 at 9:57 AM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > According to the discussion in the Scala thread, the release cycles would > stay unchanged and

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

According to the discussion in the Scala thread, the release cycles would stay unchanged and are still part of the mxnet releases. Nan Zhu schrieb am Mo., 12. März 2018, 17:42: > how about release cycle? > > > On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

how about release cycle? On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang wrote: > +1 > > On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu < > marco.g.ab...@googlemail.com> wrote: > > > +1 > > > > Tianqi Chen schrieb am Mo., 12. März 2018, > >

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

+1 On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > +1 > > Tianqi Chen schrieb am Mo., 12. März 2018, > 17:33: > > > +1 > > > > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier > > wrote: > > > > > It has

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

+1 Tianqi Chen schrieb am Mo., 12. März 2018, 17:33: > +1 > > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier > wrote: > > > It has been proposed that all Non-C API's follow separate versioning from > > the main mxnet C API/releases. > > > > A

Re: [VOTE] Disconnect all non-C API's from mxnet versioning

+1 On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier wrote: > It has been proposed that all Non-C API's follow separate versioning from > the main mxnet C API/releases. > > A +1 vote is in *favor of* using a different versioning for all > non-C-API's, with each API (Scala,

[VOTE] Disconnect all non-C API's from mxnet versioning

It has been proposed that all Non-C API's follow separate versioning from the main mxnet C API/releases. A +1 vote is in *favor of* using a different versioning for all non-C-API's, with each API (Scala, R, Julia, C++, etc.) having its own version. A -1 vote is *against* using a different