+1 (non-binding) to what Marco is describing.  +1 (non-binding) to getting the 
Scala bindings with the namespace change into Maven.

The general best practice for SemVer, which is used by most projects that 
employ SemVer, is to apply SemVer to the public APIs of packages that ship with 
your project.  If you have several independent APIs this could mean that they 
are versioned separately from each other, and from the overall project 
versioning mechanism.  

For example, the .NET Core library ships with a number of binaries, each with 
their own SemVerioned APIs.  They also have a high-level, 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://nodesource.com/blog/semver-a-primer/
“Semver is a scheme for interface versioning for the benefit of interface 
consumers, thus if a 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 
incompatibilities. In this case the Scala interface is clearly a separate 
entity from the C API.  I.e. changing the Scala namespace isn’t going to break 
C API users.  It does not communicate anything useful to these users if we up 
their major version in response to a Scala change, it simply breaks 
compatibility.  If we group all interfaces together, and increment whenever any 
of them has a breaking change we’ll soon be at MXNet version 587.  We’ll be 
forcing our users to check compatibility and update their dependency tracking 
constantly.  The end result is 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 for our public releases.  For each API we have an independent 
versioning system that if we can, we fix to the MXNet version.  When it makes 
sense we version these APIs independently.  So for example we could have a 
MXNet 1.2 release that ships with a 2.0 Scala API / R API.

In terms of Apache process I think shipping artifacts with a non-Apache 
namespace is a bigger issue than whatever versioning conventions we decide to 
use.

-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
the jars from the Scala package.

- Carin

On Fri, Mar 9, 2018 at 4:44 PM, YiZhi Liu <eazhi....@gmail.com> wrote:

> +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 <mnnav...@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
>

Reply via email to