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.ab...@googlemail.com> 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 <eazhi....@gmail.com> 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 <mnnav...@gmail.com>:
> > > -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.ab...@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 <zhunanmcg...@gmail.com> schrieb am Mo., 12. März 2018,
> 17:42:
> > >>
> > >> > how about release cycle?
> > >> >
> > >> >
> > >> > On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang <terrytangy...@gmail.com
> >
> > >> > wrote:
> > >> >
> > >> > > +1
> > >> > >
> > >> > > On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu <
> > >> > > marco.g.ab...@googlemail.com> wrote:
> > >> > >
> > >> > > > +1
> > >> > > >
> > >> > > > Tianqi Chen <tqc...@cs.washington.edu> schrieb am Mo., 12. März
> > >> 2018,
> > >> > > > 17:33:
> > >> > > >
> > >> > > > > +1
> > >> > > > >
> > >> > > > > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier <
> > >> > cjolivie...@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 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
> >
>

Reply via email to