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.ab...@googlemail.com> 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
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.