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 <[email protected]> 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 < > [email protected]> 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" <[email protected]> > > 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 > > > > > > >
