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

Reply via email to