mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: Publishing Scala Package/namespace change
Date Sat, 10 Mar 2018 01:41:26 GMT
user: “I’m having a problem with Scala API”.
dev: “What version?”
user: “1.4”
dev: “Is that Scala API version or MXNET version?”
user: “uhhhhhh... scala version, maybe?”
dev: “ok, which mxnet version?”
user: “i don’t know, how do I find that out?”
dev : “ummm go look in blah blah directory and tell me libmxnet.so file
date”
user: “nevermind, I’ll just use Caffe”


On Fri, Mar 9, 2018 at 4:43 PM Marco de Abreu <marco.g.abreu@googlemail.com>
wrote:

> My proposal was to have separate versioning but same release cycles -
> having separate cycles was just an idea.
>
> So how would we approach this problem in future if there's a big
> improvement on one of our language bindings? Like I said previously, it
> might be fine for this case, but we will run into the same issues for the
> next time and it's not a great user experience if we just do this
> "silently", provide no transitional solution and just replace an existing
> API with a new improved one.
>
> I would like to have a solution for this problem before we move on.
>
> -Marco
>
>
>
> On Sat, Mar 10, 2018 at 12:06 AM, Nan Zhu <zhunanmcgill@gmail.com> wrote:
>
> > I think last time we postpone it because the release is a minor version
> >
> > but actually such a change is actually affordable for a jump from 1.1 -
> 1.2
> >
> > -1 on separate versions (not following apache rules)
> >
> >
> > On Fri, Mar 9, 2018 at 2:38 PM, Chris Olivier <cjolivier01@gmail.com>
> > wrote:
> >
> > > IMHO, I don't think having separate versions and releases for the scala
> > API
> > > will work for the following reasons:
> > >
> > >    - Scala API is not its own Apache project, so we don't really have a
> > >    mechanism to release it separately and not the manpower of
> volunteers
> > to
> > >    maintain all the BS that goes along with releases
> > >    - We operate under the assumption (which is fair, I think) that the
> > >    Scala API is only compatible with the exact C API for which it was
> > built
> > >    against.  Since the Scala API ships with its own libmxnet.so, and
> > >    libmxnet.so is "stable" only at release boundaries, then it would be
> > > risky
> > >    to pick arbitrary points in the Scala evolution as "new versions"
> and
> > > birth
> > >    them into the World with just whatever mxnet commit was at the top
> at
> > > that
> > >    time
> > >
> > > I am also in favor of changing the namespace ASAP before the massive
> > > adoption of the Scala API that's about to happen, because it'll be way
> > > harder to do later.
> > >
> > > -Chris
> > >
> > >
> > > On Fri, Mar 9, 2018 at 2:09 PM, Naveen Swamy <mnnaveen@gmail.com>
> wrote:
> > >
> > > > MXNet Scala APis already generate a MXNet Core Scala package based
> off
> > > the
> > > > cpp backend already. I think customers who are building from source
> > would
> > > > love to get Maven package given that it takes so much pain.
> > > >
> > > > Are you suggesting we take MXNet-Scala APIs into a separate release
> > > cycle,
> > > > it is possible and can start with this one but It would not make a
> lot
> > of
> > > > sense to start MXNet-Scala 1.0 depending on MXNet 1.0(cpp). This
> won't
> > > very
> > > > different from breaking backward compatibility when we release a new
> > > > package.
> > > >
> > > > IMO managing separate release cycles for different language bindings
> > > could
> > > > turn into a lot of work for the community unnecessarily especially
> > since
> > > > they are closely
> > > >
> > > > On Fri, Mar 9, 2018 at 1:56 PM, Marco de Abreu <
> > > > marco.g.abreu@googlemail.com
> > > > > wrote:
> > > >
> > > > > While it has never been published, there have still been releases
> > under
> > > > > Apache and - as you mentioned - customers that build off the
> source.
> > > This
> > > > > would cause compatibility issues.
> > > > >
> > > > > In general I actively support the idea of enhancing the Scala
> > package,
> > > > but
> > > > > I think that we have to solve another problem first. At the moment,
> > all
> > > > > APIs are bound to the MXNet core versioning and vica versa.
> > > > >
> > > > > In my opinion, we should first separate the APIs from the MXNet
> core,
> > > > start
> > > > > versioning them separately and then make changes like these. While
> it
> > > > would
> > > > > be possible (although not right) to make an exception here, we
> still
> > > > don't
> > > > > solve the root problem and we are going to run into the same issues
> > > with
> > > > > the next big API update.
> > > > >
> > > > > Just to mention another example: our team got a request to rewrite
> > the
> > > > Cpp
> > > > > package, but we actually would not be able to merge it into MXNet
> > since
> > > > it
> > > > > breaks the existing Cpp package API - means we would need a major
> > > version
> > > > > increase.
> > > > >
> > > > > We really should solve this problem once and for all, giving back
a
> > lot
> > > > of
> > > > > freedom and reducing overhead in the long term.
> > > > >
> > > > > -Marco
> > > > >
> > > > > YiZhi Liu <eazhi.liu@gmail.com> schrieb am Fr., 9. März 2018,
> 22:44:
> > > > >
> > > > > > +1 for changing the namespace asap. for the maven deploy, we
can
> > have
> > > > > > it build along with pip deployment.
> > > > > >
> > > > > >
> > > > > > 2018-03-09 10:15 GMT-08:00 Naveen Swamy <mnnaveen@gmail.com>:
> > > > > > > Hi Guys,
> > > > > > >
> > > > > > > I am working on MXNet Scala Inference APIs
> > > > > > > <https://issues.apache.org/jira/browse/MXNET-50>
along with
> > > another
> > > > > > > contributor Roshani. A while back I noticed that we haven't
> been
> > > > > > publishing
> > > > > > > the scala package to Maven for a while now(last one being
> > v0.11.1a
> > > > > under
> > > > > > > the dmlc namespace).
> > > > > > > Currently users have to build the package manually and
then use
> > it,
> > > > > this
> > > > > > > hinders adoption and also is painful to build everything
from
> > > source.
> > > > > > >
> > > > > > > I also see that we haven't changed the namespace to org.apache
> > and
> > > > > > instead
> > > > > > > are still ml.dmlc namespace.
> > > > > > >
> > > > > > > I wanted to seek your opinion about changing the MXNet-Scala
> > > package
> > > > > > > namespace to org.apache for the Scala package and publish
to
> > Maven
> > > in
> > > > > the
> > > > > > > upcoming release. I understand that this probably breaks
the
> > Semver
> > > > > > > semantics that is agreed upon, However I would like to
point
> out
> > > that
> > > > > the
> > > > > > > Scala package has never been published to maven as 1.0
under
> > > > > org.apache.
> > > > > > >
> > > > > > > Open to suggestions.
> > > > > > >
> > > > > > > Thanks, Naveen
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Yizhi Liu
> > > > > > DMLC member
> > > > > > Amazon Web Services
> > > > > > Vancouver, Canada
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message