And just to make clear why I raise Spark MLLib as an example. I was arguing
that namespace changing is a very rare issue that we have to make APIs
incompatible. For other situations, the APIs evolves smoothly, MLLib
'@deprecated' 'train(RDD)', instead of removing it, and make APIs
compatible for a
>
> I'm not sure why users even need to know about the version mapping. If I'm
> only interested in the Scala package from maven, why do I care which
> version of libmxnet.so I'm using?
If users want to use a specific feature, e.g., Volta GPU support, they need
to first check which MXNet core
Since someone mentioned ABI, keep in mind that API compatibility does not
necessarily mean ABI compatibility. libpython, for example, may, within a
major version, guarantee backwards API compatibility (you can still compile
successfully), but does not guarantee ABI compatibility, as structure
"Did ML lib increase their major version after deprecating RDD?"
Answering my own question. They will increase major version after RDD is
removed. This is basically scenario 1 from above. It would mean we
release MXNet 2.0 with the Scala changes.
On Sun, Mar 11, 2018 at 9:54 PM, kellen
"Why refactoring and deprecating means separating version from mxnet core?
Apache Spark MLLib refactors and deprecates a lot (e.g., they deprecates
RDD API), our C API also deprecates things, remember there are a bunch of
xxxEx in c_api.h?"
Did ML lib increase their major version after
>
> Changing namespaces is one example of a required major version change, but
> there are more reasons like general refactoring or some deprecated APIs
> just being hard to maintain.
Why refactoring and deprecating means separating version from mxnet core?
Apache Spark MLLib refactors and
Ok, so why don’t we have two votes?
1) change namespace is a separate vote since it’s a code change and has
different voting rules (can be vetoed)
2) whether to disconnect non-C-API versioning from C-API versioning and
have parallel versioning of all non-C APIs (process rule, so majority, I
YiZhi, In general I agree that your points and examples are the ideal case,
but in the MXNet situation there are some trade-offs we have to make. Let
me try to specifically answer your points:
"Do you mean we have different version for 'ml.dmlc' namespace and
'org.apache' namespace?"
No I am not
Steffen, really thanks for the helps and I totally agree with you and Marco's
suggestions.
I will summarize the open issues and status for the review soon.
> What is your github handle?
Github ID: Patric Zhao, https://github.com/pengzhao-intel/ Da Zheng,
https://github.com/zheng-da/
I have no idea how separating Scala API version can solve the
'compatibility' problem. Do you mean we have different version for
'ml.dmlc' namespace and 'org.apache' namespace? Do these two versions
have same behavior? How to tell which Scala API version works with
which MXNet core version? By
Patric - added MKL-DNN to the project list. What is your github handle?
I do agree with Marco that we need to resolve disable tests, broken
features etc. Jira looks like the right answer to create a list of known
issues.
Questions I do have:
- do you have design docs we can link to? Does the doc
+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
12 matches
Mail list logo
