Regarding #4: Changing namespaces is one use-case, but there will be a lot more with increasing activity - we have to take the bigger picture in mind. I think it is safe to say that the other APIs have not been maintained as actively as our Python/Gluon API (which I would say could be versioned together with MXNet Core, but it does not really make a difference). This results in our APIs not reflecting all features available in MXNet (#2) or doing it in a way that we wouldn't recommend nowadays. While it is no problem to add new features to an API using a minor version change, it limits our possibilites to do a refactor. Our team, for example, got a customer that would like to see the functionality of the Cpp package being increased. During analysis, we figured that a re-engineering of that API would be more appropriate and easier maintainable. If we don't pass this vote, we won't be able to make any improvements to our less maintained APIs without a major version increment - which the community is also heavily against. We have to do #3 anyways, so it is just about having a different number set as version string - right now we're making it easy for ourselves by basically not maintaining any other than the Python interface and declining all breaking changes or refactors to APIs. I really don't see an issue in #1 - it's a simple lookup that could be done on our website. Simply select the version of MXNet you would like to have and it will provide you with the appropriate installation instructions - the same way we're already doing it.
This leaves us with three options: 1. Vote failed: No refactoring of user-facing APIs (including namespace changes) possible OR major version increase 2. Vote succeeded: Refactoring of user-facing APIs possible and only users of the changed APIs are affected while major version does not increase for other APIs. 3. Remove SemVer: We could introduce breaking changes at any point in time, but our users would be losing trust due to unexpected failures during upgrades. -Marco On Mon, Mar 12, 2018 at 9:22 PM, YiZhi Liu <[email protected]> wrote: > STRONGLY -1 (binding) as I explained in another thread 'Publishing > Scala Package/namespace change'. I think separating version is > harmful. > > 1. It is harmful to user experience > 1) Each time users want to use a specific feature, need to first > check the mxnet core version, then check which frontend work with this > core version. > 2) Each time users have problem using a frontend (Scala/R/...) > API, need to figure out which core version they are using. > 2. Frontend APIs are tightly binding to the 'MXNet Core', e.g., almost > all APIs extract operator definitions from the Core, which makes the > API version and Core version a one-on-one mapping. Then why separate? > 3. It introduces overhead for release. Now each release need to > involve a bunch of frontend release version, along with the MXNet core > release version. > 4. The only benefit I see so far is, it makes easier for Scala package > to change the namespace from ml.dmlc to org.apache (by increasing > Scala API major version id without changing the MXNet core major > version). But, > 1) It is very likely that, this is the ONLY time we benefit from > separate versioning. Changing namespace is a very rare issue that > forces us to make APIs incompatible. In other situations, the APIs > evolves smoothly which can stay compatible for a long time. > 2) We can still discuss whether we have to change the major version. > 3) Even the answer to 2) is Yes, I think it is affordable to wait > for MXNet 2.0 to change 'ml.dmlc' to 'org.apache' > 5. Other Apache projects, e.g., Apache Spark, have PySpark (Python > frontend API), SparkR (R frontend API), MLLib, GraphX, etc, same > version as the Spark Core, as well as the Scala/Java API. I feel it > convenient since every time I check a document, say, MLLib 1.6.0, I > can tell it works with Spark Core 1.6.0 and GraphX 1.6.0. And I can > expect when I use Python API 1.6.0, it will behave the same. > > and for +1 votings, do you mean to separate Python/Gluon API versioning as > well? > > 2018-03-12 11:18 GMT-07:00 Naveen Swamy <[email protected]>: > > -1 for different versioning, it not only be maintenance nightmare but > also > > more importantly confusing to users, > > > > > > On Mon, Mar 12, 2018 at 9:57 AM, Marco de Abreu < > > [email protected]> wrote: > > > >> According to the discussion in the Scala thread, the release cycles > would > >> stay unchanged and are still part of the mxnet releases. > >> > >> Nan Zhu <[email protected]> schrieb am Mo., 12. März 2018, 17:42: > >> > >> > how about release cycle? > >> > > >> > > >> > On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang <[email protected]> > >> > wrote: > >> > > >> > > +1 > >> > > > >> > > On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu < > >> > > [email protected]> wrote: > >> > > > >> > > > +1 > >> > > > > >> > > > Tianqi Chen <[email protected]> schrieb am Mo., 12. März > >> 2018, > >> > > > 17:33: > >> > > > > >> > > > > +1 > >> > > > > > >> > > > > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier < > >> > [email protected] > >> > > > > >> > > > > wrote: > >> > > > > > >> > > > > > It has been proposed that all Non-C API's follow separate > >> > versioning > >> > > > from > >> > > > > > the main mxnet C API/releases. > >> > > > > > > >> > > > > > A +1 vote is in *favor of* using a different versioning for > all > >> > > > > > non-C-API's, with each API (Scala, R, Julia, C++, etc.) having > >> its > >> > > own > >> > > > > > version. > >> > > > > > > >> > > > > > A -1 vote is *against* using a different versioning for all > >> > > > non-C-API's, > >> > > > > > with all API's (Scala, R, Julia, C++, etc.) sharing the mxnet > >> > > version. > >> > > > > > > >> > > > > > This vote will conclude on Monday, March 19, 2018. > >> > > > > > > >> > > > > > Thanks, > >> > > > > > -Chris > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > > -- > Yizhi Liu > DMLC member > Amazon Web Services > Vancouver, Canada >
