mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@googlemail.com>
Subject Re: Publishing Scala Package/namespace change
Date Sat, 10 Mar 2018 00:42:58 GMT
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