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 specific feature, need to first
check the mxnet core version, then check which frontend work with this
core version.
    2) Each time users have problem using a frontend (Scala/R/...)
API, need to figure out which core version they are using.

And as I describe in my #5. Imagine an inverse situation. When someone
has a model trained by gluon 1.6.0, he want to deploy it to JVM, what
Scala API version should he use? 1.6.0? No. And which R package
version he should use? It is still different from either Gluon version
or Scala API version. What a nightmare.
"

2018-03-12 16:10 GMT-07:00 kellen sunderland <kellen.sunderl...@gmail.com>:
> @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.  I don't see how a user can use the wrong library or be confused
> here unless the instructions on this page are incorrect:
> https://github.com/apache/incubator-mxnet/tree/master/scala-package
>
> On Tue, Mar 13, 2018 at 12:02 AM, Rahul Huilgol <rahulhuil...@gmail.com>
> wrote:
>
>> -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 to make this change?
>> Why do we have to 'wait' for 2.0? Who tells us that it's time for a 2.0
>> version?
>>
>> I think expecting a user to look up version numbers on the website and
>> ensure compatibility as suggested above, is not a simple task. Most users
>> might not even know how the backend and frontend integrate. They might not
>> even know that there is a C API which powers the frontends. Even knowing
>> how to look up documentation for a particular version of MXNet is a
>> non-trivial task right now. (And there are pages in a version's
>> documentation which link to a file in another version). We should avoid
>> introducing more complexity into the process. As developers we tend to
>> overlook the important aspect of user experience. I think we should take a
>> step back and look at this from the perspective of a user, not from that of
>> a developer who works closely with MXNet.
>>
>> Regards,
>> Rahul
>>
>> On Mon, Mar 12, 2018 at 3:12 PM, Roshani Nagmote <
>> roshaninagmo...@gmail.com>
>> wrote:
>>
>> > -1 for different versioning.
>> >
>> > I feel its just added confusion for users.
>> >
>> > On Mon, Mar 12, 2018 at 2:35 PM, YiZhi Liu <eazhi....@gmail.com> 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 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 would
>> be
>> > > more appropriate and easier maintainable.
>> > > I cannot agree as an engineer. Why not keep old API and add new ones?
>> > > Just like in c_api.h, we added xxxEx while did not remove xxx, which
>> > > keeps APIs compatible.
>> > >
>> > > > I think it is safe to say that the other APIs have not been
>> maintained
>> > > as actively as our Python/Gluon API.
>> > > Are you saying, if an API is maintained actively and is widely used,
>> > > then it should be versioned together with MXNet Core?
>> > > Interesting, maybe instead we should have another discussion to decide
>> > > whether to remove some of the 'inactive' frontend bindings from the
>> > > repo.
>> > >
>> > > > We have to do #3 anyways, so it is just about having a different
>> number
>> > > set as version string.
>> > > A release with 6 different versions and 5 mappings?
>> > >
>> > > > I really don't see an issue in #1 - it's a simple lookup that could
>> be
>> > > done on our website.
>> > > Please be careful to say 'simple', each time we introduce an
>> > > additional step, we lose a number of our potential users.
>> > > And as I describe in my #5. Imagine an inverse situation. When someone
>> > > has a model trained by gluon 1.6.0, he want to deploy it to JVM, what
>> > > Scala API version should he use? 1.6.0? No. And which R package
>> > > version he should use? It is still different from either Gluon version
>> > > or Scala API version. What a nightmare.
>> > >
>> > > 2018-03-12 14:11 GMT-07:00 Chris Olivier <cjolivie...@gmail.com>:
>> > > > 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 affected while major version does
>> > not
>> > > > increase for other APIs. 3. Remove SemVer: We could introduce
>> breaking
>> > > > changes at any point in time, but our users would be losing trust due
>> > to
>> > > > unexpected failures during upgrades.*
>> > > >
>> > > > What you're describing is not what this vote is about.  This vote is
>> > > > whether to separate mxnet and API versioning.
>> > > > Please try to stay on task.
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Mar 12, 2018 at 1:56 PM, Marco de Abreu <
>> > > > marco.g.ab...@googlemail.com> wrote:
>> > > >
>> > > >> 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
>> > > >> together with MXNet Core, but it does not really make a difference).
>> > > This
>> > > >> results in our APIs not reflecting all features available in MXNet
>> > (#2)
>> > > or
>> > > >> doing it in a way that we wouldn't recommend nowadays. While it is
>> no
>> > > >> problem to add new features to an API using a minor version change,
>> it
>> > > >> limits our possibilites to do a refactor. Our team, for example,
>> got a
>> > > >> customer that would like to see the functionality of the Cpp package
>> > > being
>> > > >> increased. During analysis, we figured that a re-engineering of that
>> > API
>> > > >> would be more appropriate and easier maintainable. If we don't pass
>> > this
>> > > >> vote, we won't be able to make any improvements to our less
>> maintained
>> > > APIs
>> > > >> without a major version increment - which the community is also
>> > heavily
>> > > >> against. We have to do #3 anyways, so it is just about having a
>> > > different
>> > > >> number set as version string - right now we're making it easy for
>> > > ourselves
>> > > >> by basically not maintaining any other than the Python interface and
>> > > >> declining all breaking changes or refactors to APIs. I really don't
>> > see
>> > > an
>> > > >> issue in #1 - it's a simple lookup that could be done on our
>> website.
>> > > >> Simply select the version of MXNet you would like to have and it
>> will
>> > > >> provide you with the appropriate installation instructions - the
>> same
>> > > way
>> > > >> we're already doing it.
>> > > >>
>> > > >> 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 affected while major version does not
>> increase
>> > > for
>> > > >> other APIs.
>> > > >> 3. Remove SemVer: We could introduce breaking changes at any point
>> in
>> > > time,
>> > > >> but our users would be losing trust due to unexpected failures
>> during
>> > > >> upgrades.
>> > > >>
>> > > >> -Marco
>> > > >>
>> > > >>
>> > > >> On Mon, Mar 12, 2018 at 9:22 PM, YiZhi Liu <eazhi....@gmail.com>
>> > wrote:
>> > > >>
>> > > >> > 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 frontend work with
>> > this
>> > > >> > core version.
>> > > >> >     2) Each time users have problem using a frontend (Scala/R/...)
>> > > >> > API, need to figure out which core version they are using.
>> > > >> > 2. Frontend APIs are tightly binding to the 'MXNet Core', e.g.,
>> > almost
>> > > >> > all APIs extract operator definitions from the Core, which makes
>> the
>> > > >> > API version and Core version a one-on-one mapping. Then why
>> > separate?
>> > > >> > 3. It introduces overhead for release. Now each release need to
>> > > >> > involve a bunch of frontend release version, along with the MXNet
>> > core
>> > > >> > release version.
>> > > >> > 4. The only benefit I see so far is, it makes easier for Scala
>> > package
>> > > >> > to change the namespace from ml.dmlc to org.apache (by increasing
>> > > >> > Scala API major version id without changing the MXNet core major
>> > > >> > version). But,
>> > > >> >    1) It is very likely that, this is the ONLY time we benefit
>> from
>> > > >> > separate versioning. Changing namespace is a very rare issue that
>> > > >> > forces us to make APIs incompatible. In other situations, the APIs
>> > > >> > evolves smoothly which can stay compatible for a long time.
>> > > >> >    2) We can still discuss whether we have to change the major
>> > > version.
>> > > >> >    3) Even the answer to 2) is Yes, I think it is affordable to
>> wait
>> > > >> > for MXNet 2.0 to change 'ml.dmlc' to 'org.apache'
>> > > >> > 5. Other Apache projects, e.g., Apache Spark, have PySpark (Python
>> > > >> > frontend API), SparkR (R frontend API), MLLib, GraphX, etc, same
>> > > >> > version as the Spark Core, as well as the Scala/Java API. I feel
>> it
>> > > >> > convenient since every time I check a document, say, MLLib 1.6.0,
>> I
>> > > >> > can tell it works with Spark Core 1.6.0 and GraphX 1.6.0. And I
>> can
>> > > >> > expect when I use Python API 1.6.0, it will behave the same.
>> > > >> >
>> > > >> > and for +1 votings, do you mean to separate Python/Gluon API
>> > > versioning
>> > > >> as
>> > > >> > well?
>> > > >> >
>> > > >> > 2018-03-12 11:18 GMT-07:00 Naveen Swamy <mnnav...@gmail.com>:
>> > > >> > > -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 are still part of the mxnet releases.
>> > > >> > >>
>> > > >> > >> Nan Zhu <zhunanmcg...@gmail.com> schrieb am Mo., 12. März
>> 2018,
>> > > >> 17:42:
>> > > >> > >>
>> > > >> > >> > how about release cycle?
>> > > >> > >> >
>> > > >> > >> >
>> > > >> > >> > On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang <
>> > > terrytangy...@gmail.com
>> > > >> >
>> > > >> > >> > wrote:
>> > > >> > >> >
>> > > >> > >> > > +1
>> > > >> > >> > >
>> > > >> > >> > > On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu <
>> > > >> > >> > > marco.g.ab...@googlemail.com> wrote:
>> > > >> > >> > >
>> > > >> > >> > > > +1
>> > > >> > >> > > >
>> > > >> > >> > > > Tianqi Chen <tqc...@cs.washington.edu> schrieb am Mo.,
>> 12.
>> > > März
>> > > >> > >> 2018,
>> > > >> > >> > > > 17:33:
>> > > >> > >> > > >
>> > > >> > >> > > > > +1
>> > > >> > >> > > > >
>> > > >> > >> > > > > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier <
>> > > >> > >> > cjolivie...@apache.org
>> > > >> > >> > > >
>> > > >> > >> > > > > 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, R, Julia, C++,
>> etc.)
>> > > >> having
>> > > >> > >> its
>> > > >> > >> > > own
>> > > >> > >> > > > > > version.
>> > > >> > >> > > > > >
>> > > >> > >> > > > > > A -1 vote is *against* using a different versioning
>> for
>> > > all
>> > > >> > >> > > > non-C-API's,
>> > > >> > >> > > > > > with all API's (Scala, R, Julia, C++, etc.) sharing
>> the
>> > > >> mxnet
>> > > >> > >> > > version.
>> > > >> > >> > > > > >
>> > > >> > >> > > > > > This vote will conclude on Monday, March 19, 2018.
>> > > >> > >> > > > > >
>> > > >> > >> > > > > > Thanks,
>> > > >> > >> > > > > > -Chris
>> > > >> > >> > > > > >
>> > > >> > >> > > > >
>> > > >> > >> > > >
>> > > >> > >> > >
>> > > >> > >> >
>> > > >> > >>
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > --
>> > > >> > Yizhi Liu
>> > > >> > DMLC member
>> > > >> > Amazon Web Services
>> > > >> > Vancouver, Canada
>> > > >> >
>> > > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Yizhi Liu
>> > > DMLC member
>> > > Amazon Web Services
>> > > Vancouver, Canada
>> > >
>> >
>>
>>
>>
>> --
>> Rahul Huilgol
>>



-- 
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada

Reply via email to