From dev-return-2385-archive-asf-public=cust-asf.ponee.io@mxnet.incubator.apache.org Sat Mar 10 01:43:45 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 CFDC518064A for ; Sat, 10 Mar 2018 01:43:44 +0100 (CET) Received: (qmail 99608 invoked by uid 500); 10 Mar 2018 00:43:43 -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 99592 invoked by uid 99); 10 Mar 2018 00:43:43 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 10 Mar 2018 00:43:43 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id B2EABC1B30 for ; Sat, 10 Mar 2018 00:43:42 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id gniZj39UqfcE for ; Sat, 10 Mar 2018 00:43:41 +0000 (UTC) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 6415D5F5B1 for ; Sat, 10 Mar 2018 00:43:40 +0000 (UTC) Received: by mail-lf0-f48.google.com with SMTP id v9-v6so15538179lfa.11 for ; Fri, 09 Mar 2018 16:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=14oTK4O/oEzHvWrRx+ZlfyAfqgnEz+AlrYram4Ttn/4=; b=stieGIAjsHIksLyE9cAW3yaU8bzAT2MEyoprdIMD1C4yQsIElRqrppjM1YT/qbRzir ubmIPeoAbO3d0r7CE9T+dAn+zvrF1uUp8toaBTCUDkXDbxdt/z3JdRSv0VykNpHKfXzm naHSXMCzs32KiRMpIlzIR1ZKYPEySRKi6xzS50uTEUxG5NQW7EE8fAXQFfKipP2tyq5a w6i6GoGXA3GfDG0TAN0o7+y8dsdZHwEX/iuaOLb1YWybgTloBAcaTWpXt61TBgxVKFrH ovQ0w2i+kV9dzD6uBdb8fgJCaoHQ5nCXisnYlEd4oe+6O7a1etrq2HpXlzmbyAzDoTey cRUQ== 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=14oTK4O/oEzHvWrRx+ZlfyAfqgnEz+AlrYram4Ttn/4=; b=GWnHjycO64dL8GzbZabNcHUlHCzWbnlTxQDXtapQ6dejfZeGH4xh7v/+UfsqP55BFJ flzGa4juWSXchYPyOl/3jMds2yciW3qFyHhpjXJgP1yIlgdiJsTUfj6XIWYWclYczBST WPnLvhtXDeUv5HEavMJR6ZnLzzL56y/tV39NnEPBxgK56Xyiaz1E0Ji3zi9TOPd1ZgyK 7GY5OVX3kH2wFMleOKXRkJecMs1jtfVk9rBneIEfe0rJOHTRfljsqOlrhmLtchOn4Ly0 CYUkLYdxgiz3464ViD7Y4dryRgjSrTXavJA5FjYIpVQ22eK8axIWkENLbefH+KKLRNKU laLw== X-Gm-Message-State: AElRT7E7N7pdZ8pbzrpJ0GU3UtV0Yd5DvEGSL6qcTVIl57cG/VutiTB6 gqWuLzX7EFSCOPkdI9aiTQC9ZWVZc37+gh1sPak= X-Google-Smtp-Source: AG47ELvzRuQaJDekkApCG7p5KgCt8EPYX9NUyMJhFTeVpFqX/KioJrs2ggrnLfu8wCXLWojgqEsmDKrUSo1qOv6wB2k= X-Received: by 10.46.124.8 with SMTP id x8mr197706ljc.121.1520642618707; Fri, 09 Mar 2018 16:43:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.235.88 with HTTP; Fri, 9 Mar 2018 16:42:58 -0800 (PST) In-Reply-To: References: From: Marco de Abreu Date: Sat, 10 Mar 2018 01:42:58 +0100 Message-ID: Subject: Re: Publishing Scala Package/namespace change To: dev@mxnet.incubator.apache.org Content-Type: multipart/alternative; boundary="f4f5e8075a141e55a1056704336e" --f4f5e8075a141e55a1056704336e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 the same issues for the next time and it's not a great user experience if we just do this "silently", provide no transitional solution and just replace an existing API with a new improved one. I would like to have a solution for this problem before we move on. -Marco On Sat, Mar 10, 2018 at 12:06 AM, Nan Zhu wrote: > 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 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 volunteer= s > to > > maintain all the BS that goes along with releases > > - We operate under the assumption (which is fair, I think) that the > > Scala API is only compatible with the exact C API for which it was > built > > against. Since the Scala API ships with its own libmxnet.so, and > > libmxnet.so is "stable" only at release boundaries, then it would be > > risky > > to pick arbitrary points in the Scala evolution as "new versions" an= d > > birth > > them into the World with just whatever mxnet commit was at the top a= t > > that > > time > > > > I am also in favor of changing the namespace ASAP before the massive > > adoption of the Scala API that's about to happen, because it'll be way > > harder to do later. > > > > -Chris > > > > > > On Fri, Mar 9, 2018 at 2:09 PM, Naveen Swamy wrote= : > > > > > MXNet Scala APis already generate a MXNet Core Scala package based of= f > > 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 possible and can start with this one but It would not make a lo= t > of > > > sense to start MXNet-Scala 1.0 depending on MXNet 1.0(cpp). This won'= t > > very > > > different from breaking backward compatibility when we release a new > > > package. > > > > > > IMO managing separate release cycles for different language bindings > > could > > > turn into a lot of work for the community unnecessarily especially > since > > > they are closely > > > > > > On Fri, Mar 9, 2018 at 1:56 PM, Marco de Abreu < > > > marco.g.abreu@googlemail.com > > > > wrote: > > > > > > > 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 problem first. At the moment, > all > > > > APIs are bound to the MXNet core versioning and vica versa. > > > > > > > > In my opinion, we should first separate the APIs from the MXNet cor= e, > > > start > > > > versioning them separately and then make changes like these. While = it > > > would > > > > be possible (although not right) to make an exception here, we stil= l > > > don't > > > > solve the root problem and we are going to run into the same issues > > with > > > > the next big API update. > > > > > > > > Just to mention another example: our team got a request to rewrite > the > > > Cpp > > > > package, but we actually would not be able to merge it into MXNet > since > > > it > > > > breaks the existing Cpp package API - means we would need a major > > version > > > > increase. > > > > > > > > We really should solve this problem once and for all, giving back a > lot > > > of > > > > freedom and reducing overhead in the long term. > > > > > > > > -Marco > > > > > > > > YiZhi Liu schrieb am Fr., 9. M=C3=A4rz 2018, = 22:44: > > > > > > > > > +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 > > > > > > contributor Roshani. A while back I noticed that we haven't bee= n > > > > > 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 ou= t > > 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 > > > > > > > > > > > > > > > --f4f5e8075a141e55a1056704336e--