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
>

Reply via email to