mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Larroy <>
Subject Re: Following semantic versioning
Date Tue, 06 Mar 2018 19:36:37 GMT
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 <> 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" <>
> 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

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