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:

    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,

Reply via email to