Re: Publishing Scala Package/namespace change

; >> > You'll never expect a project to have a different version for > > >> > changing > > >> > > >> > 'calculate(int)' to 'calculate(float)', it should just add a > > new > > >> > > >> > function 'calculate(float)'. >

Re: Publishing Scala Package/namespace change

engine, the graph description, operators, python API, > >> > gluon > >> > > >> > API, etc. We should think carefully what we want to provide, > and > >> > what > >> > > >> > our users need. > >> > >

Re: Publishing Scala Package/namespace change

gt; >> > > >> > entity from the C API.'. Everything can be seen as a separate > >> > entity, > >> > > >> > the mxnet engine, the graph description, operators, python API, > >> > gluon > >> > > >> > API, etc. We should

Re: Publishing Scala Package/namespace change

ve the same >> > > >> > version as Spark core as well as its Scala/Java API. >> > > >> > >> > > >> > 2018-03-10 23:58 GMT-08:00 kellen sunderland < >> > > >> kellen.sunderl...@gmail.com >> > > >> > >: >> > &g

Re: Publishing Scala Package/namespace change

; > > could > > > >> > mean that they are versioned separately from each other, and from > > the > > > >> > overall project versioning mechanism. > > > >> > > > > > >> > > For example, the .NET Core lib

Re: Publishing Scala Package/namespace change

, easy > to > > >> > understand version for the package as a whole: > > >> > https://docs.microsoft.com/en-us/dotnet/core/versions/. > > >> > > > > >> > > Nodesource has a good description of this: > > >> http://nodesou

Re: Publishing Scala Package/namespace change

tool has multiple interfaces, e.g. an > API > >> > and a CLI, these interfaces may evolve independent versioning.” > >> > > > >> > > SemVer at its core is a communication mechanism to inform developers > >> of > >> > incompatibiliti

Re: Publishing Scala Package/namespace change

s that our users will > stop > > pulling in new versions of the library. > > > > > > What I would propose is that (1) we have a high-level SemVer system > that > > tracks our C_API. This is the ‘MXNet’ version that we generally refer to > > and emphasize f

Re: Publishing Scala Package/namespace change

-Kellen > > From: Carin Meier > Sent: Saturday, March 10, 2018 1:41 PM > To: dev@mxnet.incubator.apache.org > Cc: d...@mxnet.apache.org > Subject: Re: Publishing Scala Package/namespace change > > +1 as well. I'm actively developing a Clojure package for MXNet that uses &g

RE: Publishing Scala Package/namespace change

@mxnet.incubator.apache.org Cc: d...@mxnet.apache.org Subject: Re: Publishing Scala Package/namespace change +1 as well. I'm actively developing a Clojure package for MXNet that uses the jars from the Scala package. - Carin On Fri, Mar 9, 2018 at 4:44 PM, YiZhi Liu <eazhi@gmail.com> wrote:

Re: Publishing Scala Package/namespace change

+1 as well. I'm actively developing a Clojure package for MXNet that uses the jars from the Scala package. - Carin On Fri, Mar 9, 2018 at 4:44 PM, YiZhi Liu wrote: > +1 for changing the namespace asap. for the maven deploy, we can have > it build along with pip deployment.

Re: Publishing Scala Package/namespace change

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: “uhh... 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

Re: Publishing Scala Package/namespace change

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

Re: Publishing Scala Package/namespace change

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 wrote: > IMHO, I don't

Re: Publishing Scala Package/namespace change

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

Re: Publishing Scala Package/namespace change

I agree, separate release cycles would cause a lot of hassle and grant now visible benefit, I'd bind these to the main release cycles. But I would separate the versioning of each package. At the moment, we are bound by the least common denominator in terms of API changes and versions. While this

Re: Publishing Scala Package/namespace change

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

Re: Publishing Scala Package/namespace change

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

Re: Publishing Scala Package/namespace change

+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 : > Hi Guys, > > I am working on MXNet Scala Inference APIs > along with another