mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: Following semantic versioning
Date Tue, 06 Mar 2018 21:11:44 GMT
This was discussed in the past and so far, it seems possible for Unix
builds, although it’s going to be messy since the compile would generally
need access to all a large portion of the headers in the source tree, since
the “things needed to create your own op” aren’t necessarily all contained
in the include/mxnet directory.

On Tue, Mar 6, 2018 at 11:40 AM kellen sunderland <
kellen.sunderland@gmail.com> wrote:

> Could we actually just define a mechanism so the libs could register their
> ops at runtime?  No linking required?
>
> On Tue, Mar 6, 2018, 8:36 PM Pedro Larroy <pedro.larroy.lists@gmail.com>
> wrote:
>
> > This is a good point. What additional blockers would there be for linking
> > against a user provided library with custom operators?
> >
> >
> >
> > On Tue, Mar 6, 2018 at 5:16 PM, Barber, Christopher <
> > Christopher.Barber@analog.com> wrote:
> >
> > > To avoid this kind of problem, you really need to support features that
> > > allow MXNet to be extended without having to resort to forking. There
> is
> > > currently no way to add C++ custom operators without forking, and no
> way
> > to
> > > share such operators across projects. This creates a perverse incentive
> > to
> > > try to get changes that may not belong into the main product.
> > >
> > > On 3/5/18, 6:26 PM, "Marco de Abreu" <marco.g.abreu@googlemail.com>
> > > wrote:
> > >
> > >     Hello,
> > >
> > >     we recently had a few cases in which it has been attempted to add
> new
> > >     functionality to old branches because a customer of somebodys
> > $DAY_JOB
> > >     requested it and was unable to switch to the latest release or that
> > > certain
> > >     feature did not make it into the release. This lead to quite a lot
> of
> > >     discussions and there was no clear standing within the community.
> > >
> > >     Just to cite semantic versioning:
> > >
> > >        1. MAJOR version when you make incompatible API changes,
> > >        2. MINOR version when you add functionality in a
> > > backwards-compatible
> > >        manner, and
> > >        3. PATCH version when you make backwards-compatible bug fixes.
> > >
> > >
> > >     We as a community agreed on following this system and I think we
> > should
> > >     either stick to it or drop it entirely - exceptions to SemVer are
> > > usually
> > >     discouraged. While I see that adding functionality might be a minor
> > > thing,
> > >     I don't think that we should educate our users into expecting us to
> > >     backport new features. The development happening on the Apache
> MXNet
> > >     repository should not be influenced by something like this;
> > especially
> > >     considering that whoever supports that customer on their $DAY_JOB
> can
> > >     assist them at creating a fork and cherrypicking that feature. But
> I
> > > don't
> > >     see much reason why we're running against best pracitices. One
> > > important
> > >     thing to note here is that we're not maintaining CI on old branches
> > and
> > >     neither are we making patch releases - so what do these users do?
> > > Compile
> > >     off a stale development branch with unvalidated changes?
> > >
> > >     In my opinion this whole topic is just causing trouble and
> > > fragementation
> > >     on our end. If a features doesn't make it into the release (for
> > > whatever
> > >     reason), so be it. But I think we should discuss this topic and
> > > emphasize a
> > >     no-exceptions-rule to SemVer.
> > >
> > >     Best regards,
> > >     Marco
> > >
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message