I agree, separate release cycles would cause a lot of hassle and grant now visible benefit, I'd bind these to the main release cycles. But I would separate the versioning of each package.
At the moment, we are bound by the least common denominator in terms of API changes and versions. While this gives stability to our users, it limits us in our development since we have to consider backwards compatibility for more than half a dozen languages. Especially considering this being an open source project, it's hard to manage this without significant constraints. With that proposal we would have the core of MXNet as some type of hardened and "compact" but fully functional and backwards compatible kernel with a C/C++ API. This would be the main version of MXNet. If there is suddenly a big community effort to heavily improve a certain API (like Scala), we would not block them with semver being the reason but just increase the version of that specific API. This gives us flexibility and our customers the possibility to benefit from an extensively improved API. Something we also could consider with this clear separation would be to give the possibility to have a legacy API for some time and basically offer two versions. We would be maintaining both for a few months to give customers the possibility to migrate and then remove it. At the moment, a layout like this is hard to pull off. I think we should really work on this topic as a community and provide a good and maintainable solution. In the end, it's a huge plus (that is being appreciated by our users) for MXNet that we are offering such a variety of APIs. Now we need a concept to maintain them properly. -Marco Naveen Swamy <mnnav...@gmail.com> schrieb am Fr., 9. März 2018, 23:10: > 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 > > > > > >
