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 <zhunanmcg...@gmail.com> 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 <cjolivie...@gmail.com> > 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 volunteers > 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" and > > birth > > them into the World with just whatever mxnet commit was at the top at > > 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 <mnnav...@gmail.com> wrote: > > > > > MXNet Scala APis already generate a MXNet Core Scala package based off > > 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 lot > 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.ab...@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 core, > > > start > > > > versioning them separately and then make changes like these. While it > > > would > > > > be possible (although not right) to make an exception here, we still > > > 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 <eazhi....@gmail.com> schrieb am Fr., 9. März 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 <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 > > > > > > > > > > > > > > >
