From dev-return-2431-archive-asf-public=cust-asf.ponee.io@mxnet.incubator.apache.org Mon Mar 12 22:12:02 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B872718064D for ; Mon, 12 Mar 2018 22:12:01 +0100 (CET) Received: (qmail 34053 invoked by uid 500); 12 Mar 2018 21:12:00 -0000 Mailing-List: contact dev-help@mxnet.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mxnet.incubator.apache.org Delivered-To: mailing list dev@mxnet.incubator.apache.org Received: (qmail 34021 invoked by uid 99); 12 Mar 2018 21:12:00 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2018 21:12:00 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id A207CC0032 for ; Mon, 12 Mar 2018 21:11:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.148 X-Spam-Level: *** X-Spam-Status: No, score=3.148 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id m_sJ27bJmg8O for ; Mon, 12 Mar 2018 21:11:56 +0000 (UTC) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 121605F3B8 for ; Mon, 12 Mar 2018 21:11:56 +0000 (UTC) Received: by mail-io0-f176.google.com with SMTP id h23so13145626iob.11 for ; Mon, 12 Mar 2018 14:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xmD8yZN8lrb4kmeCLBguNwycmmat2Dx/rrOMeaQKWi0=; b=rTX/ZbnMETJmUEdU3eou80GCWKh+58pLXpa8ZNWCCP/YdNm0eXfs/FuwhBRwqeHriv 7Sni2yXUtaEEVEraN9mFDP1i+tEEP1Uut8z+pVL3GIoQ4ftWz56hAzgRT7MOkSXv2hyw wYKUo+cyTpIK+ZNetObZ0yzkHriVGCD6bdI4uaJFeKvbSV9bfakvZqSnNxtzP9iUHIiR IpUBqvMSlNJJvI1KkDnwNb5wazWKqLN1N5pGHNoknEOeuo5QhDZfthajIUkKTTzNJWLc o0/XwR2jAgP4FE82RvQaTLD9zDTNO04YpMwKgC0uFcbz39yOHF9Ku6fzHYV++20XyQlB b0jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xmD8yZN8lrb4kmeCLBguNwycmmat2Dx/rrOMeaQKWi0=; b=Qz8tsedXk269082/crOFR1uup35HTuUwYLcpC4s5hEa3JqJLqMD6TlQghqJ/CVcyXj Kl68ldoceqoeCXaQmJEAqp7cSZodMregmd9gmGqxVa8ssSJ9WGWUfatrXamRKfHbR5LA MZxbwxLXYuyZlKG0mKDiz+VhSqfjZHDUlJ11knUO0tQDVLyoXsGlp4B1TzOivUGxdjlb AKdgNseWm1CYgF5uLCEcWDru5VggPnRGD/tyTIf3/EgRq+hWnW0clFsrrsNpM68ypXyY /qOEDvDdMMdAkFjBE2/KlExiYdz8p/TG/DFILqZ2bho4VJ7O58/+8PjoxGHui9CU6CT/ Jnqg== X-Gm-Message-State: AElRT7Ho9UhUC8diJmzGFB8+Z5YkLaJkoPqa205GZnCLKgcVMOdrdCm2 ixH4FH5eLF9k9KCogf74cDsS5uXeEW6nQFe1oKZlpQ== X-Google-Smtp-Source: AG47ELtP9YN8Q9qa+/GYEh9A1wNkaIMbxtTFWmxb8anPOAMloAcu1btJyGBOEjbYukSiKsV3E+dN3c8OgmB9qDdqvaQ= X-Received: by 10.107.138.228 with SMTP id c97mr4753981ioj.197.1520889115000; Mon, 12 Mar 2018 14:11:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.59.86 with HTTP; Mon, 12 Mar 2018 14:11:54 -0700 (PDT) In-Reply-To: References: From: Chris Olivier Date: Mon, 12 Mar 2018 14:11:54 -0700 Message-ID: Subject: Re: [VOTE] Disconnect all non-C API's from mxnet versioning To: dev@mxnet.incubator.apache.org Content-Type: multipart/alternative; boundary="001a113eceea714db405673d9704" --001a113eceea714db405673d9704 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Marco, you're mixing votes again. * 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.* What you're describing is not what this vote is about. This vote is whether to separate mxnet and API versioning. Please try to stay on task. On Mon, Mar 12, 2018 at 1:56 PM, Marco de Abreu < marco.g.abreu@googlemail.com> wrote: > Regarding #4: Changing namespaces is one use-case, but there will be a lo= t > more with increasing activity - we have to take the bigger picture in min= d. > 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) o= r > 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 bein= g > 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 AP= Is > 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 ourselv= es > by basically not maintaining any other than the Python interface and > declining all breaking changes or refactors to APIs. I really don't see a= n > 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 user= s > of the changed APIs are affected while major version does not increase fo= r > other APIs. > 3. Remove SemVer: We could introduce breaking changes at any point in tim= e, > 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 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 : > > > -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 < > > > marco.g.abreu@googlemail.com> 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 schrieb am Mo., 12. M=C3=A4rz 2018, > 17:42: > > >> > > >> > how about release cycle? > > >> > > > >> > > > >> > On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang > > > >> > wrote: > > >> > > > >> > > +1 > > >> > > > > >> > > On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu < > > >> > > marco.g.abreu@googlemail.com> wrote: > > >> > > > > >> > > > +1 > > >> > > > > > >> > > > Tianqi Chen schrieb am Mo., 12. M= =C3=A4rz > > >> 2018, > > >> > > > 17:33: > > >> > > > > > >> > > > > +1 > > >> > > > > > > >> > > > > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier < > > >> > cjolivier01@apache.org > > >> > > > > > >> > > > > 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 fo= r > > 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 al= l > > >> > > > 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 > > > --001a113eceea714db405673d9704--