Please cast your vote only on the subject at hand. This is leading to confusion and unnecessary discussion/wasting time, you can start a new thread if you so like.
I really would want to make progress on getting the Scala API to this release. On Mon, Mar 12, 2018 at 2:11 PM, Chris Olivier <[email protected]> wrote: > 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 < > [email protected]> wrote: > > > 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 > > > > > >
